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
I have to ask: what does renaming really buy us? The only purpose of
introducing this class in RC6, as far as I can tell, was to reserve the
'Date' name for future use. Since this goal is clearly unachievable,
what is the point of keeping a barely functional class around (as
PhpDate)? In my opinion, we should remove it (#ifdef it out), and wait
until we are ready for the full implementation and can pick a good
name, or until we have namespaces and can use them to separate PHP's
own classes.
- Andrei
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.
So you're also for letting PEAR dictate what PHP has and not the other
way around? Somehow this doesn't sound right.
--Jani
I have to ask: what does renaming really buy us? The only purpose of
introducing this class in RC6, as far as I can tell, was to reserve the 'Date'
name for future use. Since this goal is clearly unachievable, what is the
point of keeping a barely functional class around (as PhpDate)? In my opinion,
we should remove it (#ifdef it out), and wait until we are ready for the full
implementation and can pick a good name, or until we have namespaces and can
use them to separate PHP's own classes.
- Andrei
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.
So you're also for letting PEAR dictate what PHP has and not the other way around? Somehow this doesn't sound right.
No, I do not let Derick decided on his own what should be commited in
a last RC. I do not let Derick decides what is good for me (c) or not.
This class was added "just because people asked" at some point and
was inside #ifdef for a very good reason, this code does not get any
agreement, is not stable (see the trivial fix from Tony today).
This ext/date problem is something I will hate to see happen again.
Not because I also work on that, it is not the 1st time that my
proposals are ignored, but because Derick thinks he can do what he
wants and when he wants, as a PHP QA member, I find this attitude
pathetic.
--Pierre
This ext/date problem is something I will hate to see happen again.
Well, it's totally your own fault. I remember the couple of times
you were asked to commit your stuff but you had some other things
to do. Now that someone did the work, you start flaming him.
Ever heard about the magic omelette? (the one that existed without
breaking some eggs.. :)
--Jani
On Sat, 26 Nov 2005 15:07:15 +0200 (EET)
sniper@iki.fi (Jani Taskinen) wrote:
This ext/date problem is something I will hate to see happen again.
Well, it's totally your own fault. I remember the couple of times you were asked to commit your stuff but you had some other things to do. Now that someone did the work, you start flaming him.
Do not lie, I was never requested to commit but you joking about the
"first commit wins" rule.
--Pierre
So you're also for letting PEAR dictate what PHP has and not the other way around? Somehow this doesn't sound right.
This is not about PEAR dictating, and the PEAR developers are not
those who would suffer from this PHP date class in the first place,
but every user of PHP and PEAR::Date as well as every PHP developer
who ever named a class Date.
The problem is only more obvious because there is a popular PEAR class
with this name.
As a side note: There was a time when I thought PEAR was kind of an
official PHP class library. You're almost implying that everyone who
has ever used PEAR classes is just stupid.
I think if PHP claims to have the right to introduce new standard
classes with very common names, there should at least be a list of
reserved class names and a notice about that fact (Know that was
proposed yesterday on this list). Better would be namespaces or a PHP_
class prefix, of course.
Regards,
Sebastian
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:ilia@prohost.org]
Sent: Friday, November 25, 2005 8:50 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Solution to date issue in 5.1The 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
Ilia Alshanetsky wrote:
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.
I don't think choosing a precedent for a class naming convention should
be done under duress like this. I say just ifdef it back out then and
put those constants back as they were before. This class doesn't buy us
anything. It's just a forward-looking thing that really shouldn't go in
unless we can all agree on what it is we are looking forward at.
-Rasmus
Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
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.I don't think choosing a precedent for a class naming convention should
be done under duress like this. I say just ifdef it back out then and
put those constants back as they were before. This class doesn't buy us
anything. It's just a forward-looking thing that really shouldn't go in
unless we can all agree on what it is we are looking forward at.
I strikes me that there is a more subtle problem here which goes beyond
just renaming Date, since we have had a period where people ARE building
their own libraries with their own classes. So while the current niggle
is Date, any new core class can potentially cause a problem. Before we
have any movement forward, a agreed method of ring fencing core classes
has to be sorted out since this was not implemented previously?
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
It seems to me that the only usable method of "ring fencing" core
classes for the long term is to use namespaces. However, the namespaces
feature is a fairly large one and obviously will not be in 5.1. We can
discuss its inclusion in 5.2, should it happen to come out, or in PHP
6, but we need to get out 5.1.1 now.
- Andrei
I strikes me that there is a more subtle problem here which goes
beyond just renaming Date, since we have had a period where people ARE
building their own libraries with their own classes. So while the
current niggle is Date, any new core class can potentially cause a
problem. Before we have any movement forward, a agreed method of ring
fencing core classes has to be sorted out since this was not
implemented previously?
Ilia Alshanetsky wrote:
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.
While there already were objections either voting for removing the class
altogether for now or using a PHP_ prefix I'd like to add another point:
If the class is renamed please also rename the class timezone which
lives in the same file. Having e.g. PHP_Date/timezone instead of
PHP_Date/PHP_Timezone seems wrong.
- Chris
On Fri, 25 Nov 2005 23:50:03 -0500
ilia@prohost.org (Ilia Alshanetsky) wrote:
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.
I have strong objection, as you know.
Rename it does not deserve the basic idea of a Date class. It does not
have to exist, period.
We can add it in time in php6 and do the required reflection and
communication about it.
--Pierre
I'd also like to see the fix to ZendEngine2/zend_language_scanner.l
rolled in to this release, its a very annoying regression.
Scott
Ilia Alshanetsky wrote:
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
Index: ext/date/php_date.c
RCS file: /repository/php-src/ext/date/php_date.c,v
retrieving revision 1.43.2.22
diff -u -p -a -d -r1.43.2.22 php_date.c
--- ext/date/php_date.c 20 Nov 2005 20:14:23 -0000 1.43.2.22
+++ ext/date/php_date.c 26 Nov 2005 04:47:25 -0000
@@ -1006,7 +1006,7 @@ static void date_register_classes(TSRMLS
{
zend_class_entry ce_date, ce_timezone;
- INIT_CLASS_ENTRY(ce_date, "date", date_funcs_date);
- INIT_CLASS_ENTRY(ce_date, "PhpDate", date_funcs_date);
ce_date.create_object = date_object_new_date;
date_ce_date = zend_register_internal_class_ex(&ce_date, NULL,NULLTSRMLS_CC);
memcpy(&date_object_handlers_date, zend_get_std_object_handlers(), sizeof(zend_object_handlers));
Index: ext/date/tests/bug33869.phpt
===================================================================
RCS file: /repository/php-src/ext/date/tests/bug33869.phpt,v
retrieving revision 1.2.2.1
diff -u -p -a -d -r1.2.2.1 bug33869.phpt
--- ext/date/tests/bug33869.phpt 17 Nov 2005 21:05:30 -0000 1.2.2.1
+++ ext/date/tests/bug33869.phpt 26 Nov 2005 04:47:25 -0000
@@ -4,17 +4,17 @@ Bug #33869 (strtotime() doesn't parse "+
<?php
date_default_timezone_set("UTC");
$tm = strtotime("2005-01-01 01:01:01");
- echo date(date::ISO8601, strtotime('+5days', $tm));
- echo date(PhpDate::ISO8601, strtotime('+5days', $tm));
echo "\n";
- echo date(date::ISO8601, strtotime('+1month', $tm));
- echo date(PhpDate::ISO8601, strtotime('+1month', $tm));
echo "\n";
- echo date(date::ISO8601, strtotime('+1year', $tm));
- echo date(PhpDate::ISO8601, strtotime('+1year', $tm));
echo "\n";
- echo date(date::ISO8601, strtotime('+5 days', $tm));
- echo date(PhpDate::ISO8601, strtotime('+5 days', $tm));
echo "\n";
- echo date(date::ISO8601, strtotime('+1 month', $tm));
- echo date(PhpDate::ISO8601, strtotime('+1 month', $tm));
echo "\n";
- echo date(date::ISO8601, strtotime('+1 year', $tm));
- echo date(PhpDate::ISO8601, strtotime('+1 year', $tm));
echo "\n";
?>
--EXPECT--
Index: ext/date/tests/bug34087.phpt
===================================================================
RCS file: /repository/php-src/ext/date/tests/bug34087.phpt,v
retrieving revision 1.1.2.3
diff -u -p -a -d -r1.1.2.3 bug34087.phpt
--- ext/date/tests/bug34087.phpt 17 Nov 2005 21:05:30 -0000 1.1.2.3
+++ ext/date/tests/bug34087.phpt 26 Nov 2005 04:47:25 -0000
@@ -6,10 +6,10 @@ date_default_timezone_set("UTC");
echo "Y/m/d: ", strtotime("2005/8/12"), "\n";
echo "Y-m-d: ", strtotime("2005-8-12"), "\n";-echo date(date::ISO8601, strtotime("2005/1/2")), "\n";
-echo date(date::ISO8601, strtotime("2005/01/02")), "\n";
-echo date(date::ISO8601, strtotime("2005/01/2")), "\n";
-echo date(date::ISO8601, strtotime("2005/1/02")), "\n";
+echo date(PhpDate::ISO8601, strtotime("2005/1/2")), "\n";
+echo date(PhpDate::ISO8601, strtotime("2005/01/02")), "\n";
+echo date(PhpDate::ISO8601, strtotime("2005/01/2")), "\n";
+echo date(PhpDate::ISO8601, strtotime("2005/1/02")), "\n";
?>
--EXPECT--
Y/m/d: 1123804800
Index: ext/date/tests/bug34676.phptRCS file: /repository/php-src/ext/date/tests/bug34676.phpt,v
retrieving revision 1.1.2.3
diff -u -p -a -d -r1.1.2.3 bug34676.phpt
--- ext/date/tests/bug34676.phpt 17 Nov 2005 21:05:30 -0000 1.1.2.3
+++ ext/date/tests/bug34676.phpt 26 Nov 2005 04:47:25 -0000
@@ -10,7 +10,7 @@ $tests = array(foreach ($tests as $test) {
$t = strtotime("2005-12-22 ". $test);
- printf("%-10s => %s\n", $test, date(date::ISO8601, $t));
- printf("%-10s => %s\n", $test, date(PhpDate::ISO8601, $t));
}?>
Index: ext/date/tests/bug34771.phptRCS file: /repository/php-src/ext/date/tests/bug34771.phpt,v
retrieving revision 1.1.2.3
diff -u -p -a -d -r1.1.2.3 bug34771.phpt
--- ext/date/tests/bug34771.phpt 17 Nov 2005 21:05:30 -0000 1.1.2.3
+++ ext/date/tests/bug34771.phpt 26 Nov 2005 04:47:25 -0000
@@ -13,7 +13,7 @@ $tests = array(foreach ($tests as $test) {
$t = strtotime("2005-12-22 ". $test);
- printf("%-10s => %s\n", $test, date(date::ISO8601, $t));
- printf("%-10s => %s\n", $test, date(PhpDate::ISO8601, $t));
}?>
Index: ext/date/tests/date_default_timezone_set-1.phptRCS file: /repository/php-src/ext/date/tests/date_default_timezone_set-1.phpt,v
retrieving revision 1.1.2.3
diff -u -p -a -d -r1.1.2.3 date_default_timezone_set-1.phpt
--- ext/date/tests/date_default_timezone_set-1.phpt 17 Nov 2005 21:05:30 -0000 1.1.2.3
+++ ext/date/tests/date_default_timezone_set-1.phpt 26 Nov 2005 04:47:25 -0000
@@ -12,10 +12,10 @@ date.timezone=
$date4 = strtotime("2005-07-12 08:00:00");echo
date_default_timezone_get(), "\n";
- echo date(date::ISO8601, $date1), "\n";
- echo date(date::ISO8601, $date2), "\n";
- echo date(date::ISO8601, $date3), "\n";
- echo date(date::ISO8601, $date4), "\n";
- echo date(PhpDate::ISO8601, $date1), "\n";
- echo date(PhpDate::ISO8601, $date2), "\n";
- echo date(PhpDate::ISO8601, $date3), "\n";
- echo date(PhpDate::ISO8601, $date4), "\n";
?>
--EXPECTF--
Strict Standards:strtotime(): It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or thedate_default_timezone_set()function. We selected 'Europe/London' for 'UTC/0.0/no DST' instead in %sdate_default_timezone_set-1.php on line 3
Index: ext/date/tests/mktime-3.phpt
===================================================================
RCS file: /repository/php-src/ext/date/tests/mktime-3.phpt,v
retrieving revision 1.1.2.1
diff -u -p -a -d -r1.1.2.1 mktime-3.phpt
--- ext/date/tests/mktime-3.phpt 17 Nov 2005 21:05:30 -0000 1.1.2.1
+++ ext/date/tests/mktime-3.phpt 26 Nov 2005 04:47:25 -0000
@@ -16,7 +16,7 @@ foreach ($tzs as $tz) {
if ($ret == FALSE) {
echo "out of range\n";
} else {
echo date("F ".date::ISO8601, $ret), "\n";
echo date("F ".PhpDate::ISO8601, $ret), "\n"; }
echo "\n";
Index: ext/date/tests/strtotime.phpt
===================================================================
RCS file: /repository/php-src/ext/date/tests/strtotime.phpt,v
retrieving revision 1.1.2.1
diff -u -p -a -d -r1.1.2.1 strtotime.phpt
--- ext/date/tests/strtotime.phpt 17 Nov 2005 21:05:30 -0000 1.1.2.1
+++ ext/date/tests/strtotime.phpt 26 Nov 2005 04:47:25 -0000
@@ -8,7 +8,7 @@ $d[] = strtotime("2005-07-14 22:30:41");
$d[] = strtotime("2005-07-14 22:30:41 GMT");foreach($d as $date) {
- echo date(date::ISO8601, $date), "\n";
- echo date(PhpDate::ISO8601, $date), "\n";
}
?>
--EXPECT
Scott MacVicar wrote:
I'd also like to see the fix to ZendEngine2/zend_language_scanner.l
rolled in to this release, its a very annoying regression.
Yes, that is a problem, and we'll have it fixed in 5.1.1
Ilia
Ilia Alshanetsky wrote:
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.
I do not think it makes sense for PHP to start prefixing internal
classes with PHP. We just need a solid userland naming guide so that PHP
can keep the right-of-way for internal naming.
As for PEAR if we find better ways of cooperating on the API level it
would be a nice dream, however the reality is that API's are a matter of
taste and traditionally PEAR developer tastes are radically different
from internals developers. This is also due to the fact that PEAR API's
are generally designed for completeness, flexibility and extensibility,
where as it seems to be that internals traditionally mainly designs for
simplicity. This again leads to the conclusion that PEAR needs to prefix
just like the rest of the PHP world.
I have attempted to write such a userland naming guide but I am a bit
scared to post it here as I expect this to result in 100 emails where
people compete with quantity instead of quality. Anyways if anyone has
sincere interest in helping please write me offlist. Obviously the
powers that are need to nod off the final version.
regards,
Lukas