On 5-Nov-06, at 12:48 PM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
When we were picking a name the discussion was public on this very
list and based on our analysis of what names people were using in
their application and what would be an ideal name DateTime was
picked.
I'm not questioning this decision. I'm talking about the policy for
further classes. Maybe I should change the topic to be clearer...
We've already established a sufficiently clear policy on this matter.
When someone adds a feature to a language which is anticipated to
cause BC breaks its merits are discussed on the list where all sides
get a chance to expression their opinion. Once that's done developers
do a quick vote and based on this vote decision is made. This is a
fairly clear, simple and transparent process.
A little thought experiment: Let's assume the number of
application classes (and the usage of those classes) is on
average higher than those of the core classes. Would that change
the situation?
The number of current users does not matter, simply because are
you not comparing equivalent things here. You are comparing
existing code to something that just came out.
Forget about all the code out there: Let's say the average
application uses its own classes 10 times and PHP core classes only
5 times, which one should have the right to the short and more
convenient name?
The language always has the best pick of namespaces, this is not just
PHP, but ANY language. The fact we've made a compromise and allows
PEAR to retain the date class IMO has been a horrible mistake, one
hopefully not to be repeated in the future.
And I'm not saying that this is the case, it's just a thought.
Come on, that can't be the solution. Think about hosting
companies for example.
They as a rule use old versions, in fact I bet you'd be hard
pressed to find a big or even a medium size hosting company
offering PHP 5.2 just now. So you have plenty of time to fix your
code.
I could be mean and ask why that is. But that's not the discussion
here. We're talking about the naming policy of classes in the long
run.
The classes/functions/constants that will be added in the future will
be based largely on the names the developers of said language
components decide upon. In the event their names present issues, such
as BC breaks there would be a review done to determine the merits of
keeping or changing the name. It is really quite simple.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
