Re: Re: revision to the standard that would make me happy

David Coallier wrote: > > > > > >> So we don't lose any of the rigor, and gain flexibility. > Does this > > >> modified sales pitch change your mind? :) > > > > > > I believe above stands as my answer. I'm happy to be swayed by a > > > majority of non-PEAR developers showing me how I'm wrong, though. > > > > ...and this is why regrettably I must say I can't support either the > > standard or its advocate, Travis, for re-election to PEAR Group. > > Someone making decisions for PEAR should be advocating *for* > PEAR, not > > against it. > indeed. > > > All due respect Greg, I'm not sure why you are bringing an issue like > that here saying: "I do not support Travis for the elections" when in > fact the whole discussion is not posted with your email. I am not > saying Travis is right and you are wrong, I am not saying you are > right and Travis is wrong, but I firmly believe and in fact know how > Travis has been trying to get PEAR and the PHP Community in general to > evolve as a whole and for that I have to say that I support him for > his courage but also dedication in trying to get the open source > projects together to make a better PHP world. > > I have stayed silent in the discussion so far and I think this is a > good time to step in. I am not always in agreement with Travis's ideas > or ways of doing things, in fact I think there's a bit of diplomacy to > be added in some emails (Both from you and him) but the fact that > someone is trying to move things towards a general standard that would > actually not be "built to accomodate PEAR" but built to accommodate > the PHP Community using previous experiences from PEAR and some great > input from a large community with many years of experience is very good. > > I do not mind if you guys have disagreements on certain points, but > comments like that are in my opinion plain spam-like and you shouldn't > slash in public for a disagreement over a standard. Of course you can > write a blog post or tweet about it or whichever media, but I strongly > believe that personal issues should be resolved either privately but > not on the project mailing list. > > I'd be happy to moderate any quarrels you guys might have and in fact > try to bring down the tension that has been present over the past few > weeks but please if you do disagree about something, post the whole story. > > I may be completely wrong but in my opinion, pear-dev shouldn't have > that kind of messages and yes you may have different with some members > but please try to resolve those issues between yourselves. Hi David, You are incorrect, actually. This is a professional disagreement, not a personal one, and it is perfectly appropriate to express that in terms of support for a candidate for public office. The problem as I see it is that Travis's contention is that the proposed standard better adheres to both existing best practices and tools. Let's take a look at existing best practices and tools for PHP: 1) the PEAR Installer is distributed with PHP 2) PEAR, Zend Framework, Solar, Horde, PHPUnit, and several others I'm probably forgetting all use the existing PEAR_Class_Naming standard 3) tools relating to classes: PEAR Installer, PHPUnit, PHPCS, phpDocumentor, Doxygen, Phing Doxygen, as a tool not written in and for PHP, is an anomaly. Of this list, only Phing is not indirectly associated with PEAR or its naming standards and all but Phing use PEAR's existing naming standards and some variant of its best practices. What he (and apparently several of the current PEAR Group members) are tacitly doing is saying that these are not in fact best practices by supporting a naming standard that radically diverges from the current "namespace" standard: using _ as a namespace separator and This_Style_Naming. In fact, the standard Travis is proposing is almost identical to Python's standard, but the Python namespace implementation is different from PHP's, and the differences are significant - much of the standard is actually designed around these differences (such as lower-casing namespace names - Python uses the equivalent of :: for both namespace separator and class method, so case is used to differentiate between namespaces and classes). Having both helped to actually design the namespace implementation for PHP, as well as having actually used the thing in a project with well over 11,000 lines of code, I can confirm that there are several serious issues with the proposed standard that are completely unnecessary that many Travis has been aware of for well over a year, and actively chooses to ignore because in his opinion the issues only occur when you don't conform to "best practices" as defined by his experience, and not by the experience of anyone using the existing PEAR standards. In fact, I have spent well over a month trying to resolve these differences over the standard, and have received no public response beyond the emphatic "Sorry, no way, and oh by the way, I don't consider the opinions of PEAR developers to be relevant to the discussion" response from Travis that I forwarded. Frankly, as the only developer actually doing any real work on PEAR2 or Pyrus, I think it is only reasonable that the administrators of the PEAR Group actually listen to issues that I discover in the process of working. It's the right of everyone on the list to disagree with me, and also the right of the PEAR Group to tell me to back off. More to the point, I suggest that supporters of the new naming standard actually try converting an existing PEAR, Solar, Zend Framework, or PEAR2 package to the new standard, and then come back and tell me you still like it. For example, I'd suggest MDB2 as a great candidate to explore the problems I've been trying so hard to bring to light. Greg