Andi Gutmans wrote:
I don't think question is only in regards to Date.
I think it's a bigger question on what the standard is for internal classes.
I couldn't agree more. The main question is who the unprefixed namespace
belongs to. I'd say it's either the core or the application but
certainly not a framework (e.g. PEAR). I think we agree so far. I'm
voting for the application as it keeps the language simple for simple
things while avoiding WTF situations ("I can call my class Time but I
can't call it Date?"). Another advantage is that it allows full reuse of
names (e.g. $foo holding an instance of class Foo which represents DB
table Foo) without having to be afraid of name clashes.
While I understand that people waiting for the Date class want to use it
and want to use it as easily as possible (no prefix) I dare to say that
most of the PHP code out there won't care about this class and shouldn't
be put in danger of incompatibility.
Although we already have quite a few classes in PHP I think we are still at
an early point and we should make the right decision now. I'd prefer that
from now on going forward we prefix all new classes with Php. In PHP 6, once
we implement namespaces for classes (yep, on my todo) then we can put those
classes in a Php namespace. This does leave some existing inconsistencies
I support that: PhpDate for now and Php:Date once we have namespaces. (I
hope I understood Andi's proposal correctly.)
Two little side-notes:
1) The absence of bug-report proves nothing as the Date class was
certainly only exposed to a very limited number of applications.
2) Remember that all the new bells and whistles should really try hard
not to make the basic usage of PHP more complicated. Dictating everybody
to prefix all their classes is Not A Good Idea(tm) IMHO.
Over and out,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
