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

>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. I understand that you guys represent a large constituency of developers and that ought to lend some credibility to your position. I also know that the heuristics of analysing exactly what percentage (or even approximately) are impossible and I stand by my claim that even though you're the maintainers of some of the more popular frameworks, I don't think your decisions are representative of the PHP developer populace. Furthermore, the last I checked, there weren't very many successful OSS projects that were run like a republic and it seems that this sort of thing is a step back into the cathedral, which makes no sense to me, as the current model for PHP development hasn't exactly failed us. Of course there are things that could be changed, or improved upon, and that decisions do eventually need to be made, but limiting discussion to the respective communities of the projects you represent is pretty limited when the the decisions you are making are theoretically going to be adopted by the general PHP population. If you want to have a set of coding standards, especially with namespacing, then anyone who intends to adopt them ought to be able to take part in that discussion and my impression is that you few fellows sat down at php|tek and made some decisions that were based on internal talks with your respective communities. I haven't been on the php general mailing list long, but I haven't seen (with a quick google) any attempt at the php-general list to open these talks to a broader audience. IMO, if you want these standards to be more than just named standards - which is the goal, no? - then you ought to fire up a bulletin board or forum somewhere and allow an open exchange of ideals, with coordinated times in IRC or some other transient medium, for people to decide. Give every issue a few weeks to simmer and a deadline, upon which anyone who's active enough to care can decide together in IRC. Do it like a bicameral legislature - IRC needs to pass with 2/3 majority, and the forum can veto it with a 2/3 majority. Or something else altogether; the point is as far as I kow, no one asked. >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. So, everyone who writes PHP and gets a say in these debates has to be either a part of PEAR2 or ZF? What if I choose to use neither, my voice no longer counts? I would bet my last penny that these two communities together do not demonstrate near a representative majority of people using them, let alone the PHP community itself. This is exclusivity based on your projects and it's not acceptable. >Third, these standards are not compulsory. You can adopt them or not. This is the sort of attitude that is going to pretty much guarantee !(widespread adoptance) of these standards. Why? Because you're very condescending and haven't even considered the fact that I choose not to use your products for reasons of my own, not because I'm incompetent. Your posts reek of "holier than thou" and a mindset that "we're doing what's best because we're doing it, and if you choose not to adopt it, it's your fault." The problem with that is, a successful standard compensates for both the people you work with and the people you don't and if you're going to write a set of standards, exclusivity of adoptance is the exact opposite of what you want. You don't want to have to say "You can adopt them or not," you should be able to say "You don't have to adopt them, but they're fairly painless to implement and there's no reason not to, everyone else is!" To put yourself in that position though, you're going to have to open the floor up completely and wholely to free discussion and exchange of ideals. Just to make a point, there's a few (minor) academic thigns wrong with your standards - you pointed these out, I think - but practically, no one bothered to consider the performance implications of having every exception be two or three layers down the inheritence tree. I can't afford the resource usage to have PHP re-calculate inheritence every time an error occurs, so I can't adopt these standards and it looks like (judging from the performance of ALL of the representative products) performance is never even a factor in these decisions (which would also explain why the adoptance in high traffic sites is so low). Perhaps it would be useful to get some feedback from people that are used to writing slimmed down and fast applications before you commit yourselves to a set of standards that's going to destroy your site's performance? But I digress, I think my point is made. >If anything, we're keeping a very close eye on the community, and >involving them as much as possible -- via our individual projects. Why is the community "them" and not "us." Your verbage betrays your arrogance, once again. A project leader is not above the community, but part of it, and if you're going to refer to "us" as "them" then perhaps you ought to re-evaluate the way you see your position within said community. I'm not trying to be personally insulting, but I don't see how a group of people that is seemingly so disconnected from the community (Ivory Tower, once again) can possibly think that they aptly speak for it. It really seems like we're beating a dead horse here, though, as this seems to have died. I'd be more than interested in contributing in whatever capacity if there's a legitimate community (that transcends individual projects) effort made, but until then, I don't see this as being productive at all. --Eddie Drapkin