|
|
|
[
Permlink
| « Hide
]
Darby Felton - 22/Aug/06 09:21 AM
Are we also removing loadClass(), then? Of course, loadClass() cannot load interface classes because it uses class_exists().
No. Zend::loadClass() serves a valid purpose by providing a mechanism for factory methods to load classes, but throw exceptions on error conditions. Loading interfaces is different, since the class using the interfaces should simply use "require_once()" directly in the file containing the source code for the class. I would think that keeping Zend::loadInterface makes more sense.
Since ZF has a concept of namespaces, and Zend::loadClass understands that, it seems logical to maintain a similar loading system for interfaces. Basically, if I call: Zend::loadClass('Zend_Controller_Router');
it seems logical that I should also be able to call: Zend::loadInterface('Zend_Controller_Router_Interface');
Well, why use loadClass()?
If you are abstracting the actual file and using a namespace for your classes, then wouldn't it make more sense to do the same for interfaces? Sorry if i sounded gruff on my last comment, wasn't intended.
I just think that a common method for utilizing namespaces for classes and interfaces should remain. barring the fact that Zend.php couldn't use that method, every other class in the ZF could use it to load needed interfaces and classes. Although currently the ZF classes seem to use require_once for interfaces instead. Is there a significant speed difference? Ok, I'll admit, I must be confused. I have read your comments and you seem to say that Zend::loadClass() is really just for factory methods, yet in tutorials on usign ZF they commonly use:
Zend::loadClass('Zend_Controller_Front');
Now, if I understand what you are saying, we should really just use: require_once('Zend/Controller/Front.php');
And leave Zend::loadClass() to the factory methods? Cute.
I notice you just added that. Shouldn't things like Coding Standards be discussed, or are you the final judge on the standards? And if I disagree with that standard, what would be the correct forum for discussion? Yes, by chance the ZF team just discussed that section and agreed to it before your posting.
Coding standards are always open for discussion. In fact we specifically moved them to the wiki to encourage improvement and discussion within the community (see numerous past emails on the topic in fw-general). I don't think the arguement "No. Zend::loadClass() serves a valid purpose by providing a mechanism for factory methods to load classes, but throw exceptions on error conditions." is exactly valid.
loadClass and the other load classes do a little more than just support factory methods. They convert names to paths and verify that the file and contents are what are being requested. None of them are needed as they are convenience methods. Hmmm .. in what way is the statement not valid? Is it not true? The statement provides the key reason why loadClass() is needed and should not be removed. Using PHP's require_once statement does allow an error to be thrown. Thus, a key reason exists for using loadClass(). The other reasons are weaker.
I don't understand why this an issue. Is Zend::loadInterface() really detracting from the Zend base class?
I prefer the function over require_once simply because it matches loadClass and does additional error checking. If it didn't exist I would write it myself. IMHO if Zend::loadInterface() is needed by some developers, then loadClass can be extended, for example like this:
static public function loadClass($class, $dirs = null, $isInterface = false) In Zend classes I think we have to use require_once (not loadClass or loadInterface), because loadClass for me is an external tool. So in project I use require_once only once Anyway if some of developers are using loadInterface, why not to leave it? I thought framework developed to make a unified tool or a wraper to frequently used functions And the main reason, why I post comment is my idea of improvement of Zend::loadClass(), described in BTW, loadClass() is not IDE/tool friendly, while require_once can be auto-completed by tools, thus providing immediate "code-time" feedback about spelling errors, unlike the runtime exceptions resulting when using loadClass() with a spelling error in its argument.
Well. Maybe you're right.
But I gues there are a lot of developers who still be using loadClass and loadInterface... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||