On 7/18/06, John Coggeshall <[EMAIL PROTECTED]> wrote:
On Tue, 2006-07-18 at 20:25 +0200, Edin Kadribasic wrote:
> But breaking even a few or "both" is still reckless, irresposible
> behaviour when all that is needed to fix the breakage is rename the
> class. Espacially because of all the bad publicity we get for breaking
> backwards compatibility for no good reason.
In my experience, we've received an equal if not greater amount of
negative publicity from a lack of consistent naming conventions. PEAR is
a library of functionality developed on top of PHP, and therefore PHP
has the first say to what to name what and everyone else moves around
that. I also think that as PHP moves from a strictly procedural language
to an ever growing OO arm, IMHO it isn't unreasonable to lay claim to
certain core class names. Moreover, I think this whole flame war is
counterproductive for us all -- can we just do a +/- vote on this and
move on to more useful concerns?
+1 for Date as the name.
I'm indeed in favour of Date.
But what I'm not in favour is:
- to add/enable features not approved right before releases (for the
3rd time, and in a row)
- to start using the common names in general without a loud,
"official" and preemptive
warning to our users (meaning not from one minor to another)
And what I cannot accept is people arguing about PEAR dictating PHP
developments. We do not, but Derick did. So please spare me the
endless "Oh Look! PEAR is crap and evil", it is actually unopportune.
And last but not least, I fully agree with Andi and you, the needs of
classes internally is growing, faster than ever before. We have to
define rules or conventions.
However I don't think that discussing it right before a RC release is
the right time. We better have to remove the controversial part (drop
the class, keep the functions) and take the time to discuss this
problem, generally and not only for Date.
Cheers,
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
