-- Andreas Möller <[email protected]> wrote (on Tuesday, 13 November 2012, 08:38 PM +0100): > > We often abbreviate ServiceManager to $services (or, in the case of > > plugin managers, "$helpers", "$plugins", "$controllers"). If we were to > > make the change for the event manager, I'd expect we'd have to rename > > them everywhere. > > That would make sense, yes. > > > This is a pretty substantial refactor for basically > > zero gain (it's an implementation detail only), and a whole lot of risk > > (miss one location, and an entire test suite or component may no longer > > work). > > It's not zero gain. If components were named after what they are and > not after what they are composed of, it would help beginners to > understand the code better. > > To me this naming scheme seems like a bad decision. > > > The variable names need only have a semantic meaning; they don't need to > > always be completely, explicitly, literally named. Short semantic names > > are a reasonable shortcut for readability of the code. > > "Events" doesn't have the same meaning as "EventManager" - at least > not to me. These naming shortcuts do not help with understanding the > code at all, seriously. What exactly is gained from using these > shortcuts? Less typing time? Less reading time? A quicker > understanding?
I think we need to agree to disagree at this point. It's clear you feel strongly about the naming. I feel equally strongly that this is a change that (a) could lead to some serious BC breaks and/or testing issues due to the shear number of changes that would need to be reviewed, and (b) would provide negligible benefit in light of (a). 3.0 would be an appropriate time to bring this up; weeks after a stable release is not the time. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
