Re: Re: PHP Standards and Best Practices for PHP 5.3+ Frameworks and Libraries

From: Date: Mon, 01 Jun 2009 17:24:54 +0000
Subject: Re: Re: PHP Standards and Best Practices for PHP 5.3+ Frameworks and Libraries
References: 1  Groups: php.standards 
Request: Send a blank email to standards-+get-26@lists.php.net to get a copy of this message
-- Eddie Drapkin <oorza2k5@gmail.com> wrote (on Monday, 01 June 2009, 12:43 PM -0400): > Call me an anonymous developer, whatever, but I think it's completely > ridiculous that a seemingly arbitrary group of people are going to hand down > standards from their ivory tower atop their cathedral. I'm going to attempt to clear up a few issues here (hopefully). First, we are not "an arbitrary group of people". We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. Second, the standards we are ratifying *have* been up for debate. Everything we discussed in the meeting at php|tek has had community review already -- primarily within the PEAR2 community, but as many of our standards are based on PEAR, this is representative of those communitites as well (speaking for the ZF community, I know we've debated the naming issues quite a bit as well). Debate on these issues could go on for decades -- standards are like the old vi vs. emacs debates; they never end. At some point, decisions must be made, and in every case, these decisions will attempt to reflect the majority use cases. As such not everyone will be happy. That's the nature of standards. Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. Why? Because by having some common standards, we can ensure easy interoperability between projects. Increasingly, developers are cherry-picking pieces from different component libraries and frameworks to build their sites. Common standards make this much, much easier to accomplish. They can use a common autoloader to resolve dependencies. If they need to debug, it's trivial to find the location of a given class file, as the rules for class resolution are the same across the projects. They can isolate exceptions types easily based on the project. The list goes on. If anything, we're keeping a very close eye on the community, and involving them as much as possible -- via our individual projects. Decisions that have been and will be made by this group will reflect the interests of those communities as best as possible. Communal decisions rarely if ever occur -- at a certain point, a small group of people needs to analyze the debates, determine the relevant issues, and make decisions. That is our intention with this group. Now, why are the people on this group making decisions? Who are these people? In most cases, the various representatives to the group were either elected or promoted to leadership of their projects. This means that the individuals on the group already have karma in the community, and are speaking as the voice of their representative communities. I think that fact speaks for itself. Feel free to rant all you like. We are not holding a gun to your head forcing you to use the standards. We are simply trying to make life easier for PHP developers by making interoperability between projects trivial. > Whether you like it or not (and based on the attitude going around in > this thread, I'm guessing you don't), the decisions made by this > "standards" group are going to be up to peer review and adoptance. > Regardless of the quality of the standards proposed in this mailing > list, the fact that you're excluding the community at large and our > input is reason enough for me to reject your standards and not adopt > them. > > I understand that the PHP internal mailing list is slow in development and > things get argued back and forth forever and ever, but is the language any > worse for this, or is it better? I'm much inclined to think the latter, as > is every other bazaar developed standard, project, language, what-have-you. > Closing standards discussion off to the public and randomly telling me, as a > PHP developer who seeks to not only contribute back to the community but > also to follow where the community leads, that I have to follow a set of > standards (that are partially inane and unbelievably restrictive in their > naming conventions, but that's another email) because Ye Of The Popular > Frameworks Hath Spoken is a total load of bullshit. I don't give two shits > if you're Jesus Christ himself, if you're going to propose a set of > standards that tens of thousands - if not more - of developers will > theoretically be following, you best be goddamn sure that they hold up under > scrutiny and peer review. And just because six people voted does not make a > standard final; the only thing that's going to make your best practices > standardized best practices is if they're adopted. > > If you want this list to succeed, come down of the high horse and listen to > what the community has to say. If this list goes moderated, I, for one, > will make it a point not to follow your ridiculous standards and thus will > end the contributions I will make to the PHP community forever. A small > group of leaders does not a community make, but rather a oligarchy, which is > exactly what the language needs right now, a rejection of the community and > everything that we do - basically telling us, as community members, that our > opinions and thoughts don't matter because we don't swing a huge userbase of > people using our frameworks. Just when there are finally viable > alternatives to PHP around, lets throw the community in the gutter. Really > smooth. > > In closing, I think that you need to re-open the floor to discussion on what > namespacing standards you decided upon and leave this list public > indefinitely. I don't know how or why you decided to seize the power of > standards' making like so, but I think it's a terrible, terrible decision. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/

« previous php.standards (#26) next »