I object your honor!
This will set the stage for any other core objects to follow the same
convention. If namespaces are in PHPs future, design wise it would make more
sense to have them in a namespace ("PHP" seems to be popular), but if this
is released now as PhpDate, moving it to a namespace won't happen because of
BC reasons. What is so pressing in this Date class (that we've never had
until a few days ago) that it can't wait for a more thought-out
discussion/decision regarding a major shift in internal development in
regards to wrapping core functionality with object interfaces?
-1 on PhpDate
+1 on ifdef'ing it
On a side note, looking at your patch, there also seems to be no set
guidelines for class naming within core. The original class name was "date",
whereas your fix was "PhpDate, "d" vs. "P". Just another indication to me
that more things need to be worked out before the first core class is
"officially" released.
Bob Silva
> -----Original Message-----
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 25, 2005 8:50 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Solution to date issue in 5.1
>
> The attached patch is a possible solution to the date *crisis*, it
> renames the class to PhpDate to avoid any namespace conflicts with pear
> or custom user classes called date.
>
> If there are no strong objection 5.1.1 (5.1.0 + this patch and nothing
> else) goes out on Monday.
>
> Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
