Matthew,
Heh, I expected some feedback on this. Point taken and accepted :)
There has been some inconsistency in the ZF for balance points between
simplicity and complexity of component APIs. Often, comparing two
extreme alternatives helps rule out alternatives, hopefully leaving a
plausible alternative in the middle. Personally, I think the sum total
of everything a junior PHP developer can learn in about one or two hours
of reading introductory material from the ZF manual ought to be at least
available as candidate material for use in the portion of ZF API's aimed
at serving the "80+%" type use cases.
Whatever the final name is for "registry()/getInstance()", it will be in
the ZF demo tutorial. However, I think using "get()" with no arguments
isn't consistent with the expectations of those who are familiar with
"getInstance()", as used elsewhere in the ZF. Thus, I'm not in favor of
changing "getInstance()" to "get()" and creating an exception.
Cheers,
Gavin
Matthew Ratzloff wrote:
All issues raised are addressed, except "Zend::registry()" vs.
"Zend_Registry::getInstance()".
What if "Zend_Registry::getRegistry()" was an alias of
"Zend_Registry::getInstance()"?
Then the user doesn't need to know or understand the connotations of
getInstance().
Perhaps we can also provide aliases for
Zend_Controller_Front::getInstance() (getController()) and
Zend_Auth::getInstance() (getAuth()).
That's sarcasm, but I'm not trying to be rude. :-) It just feels like
there's a line between ease of use and treating users like children, and
it's crossed at the point when it obfuscates the API for knowledgeable
users--in this case, those that would immediately understand what
getInstance() refers to, but might see examples using getRegistry() and be
confused as to the difference.
Instead of dumbing down the API, why not encourage users to learn about
these concepts? If one of the goals of the project is raising the overall
level of the PHP community (which isn't explicitly stated, but which I
feel is implied), hiding these concepts from novice users is not the way
to go about it.
Perhaps the manual can have a short section on design patterns, with
overviews of those found in the framework. Each component could then link
to the ones they use, to help facilitate this educational process.
-Matt
