Solution to date issue in 5.1

Andrei Zmievski

20 years ago

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

On Nov 25, 2005, at 8:50 PM, Ilia Alshanetsky wrote:

Jani Taskinen

20 years ago

So you're also for letting PEAR dictate what PHP has and not the other
way around? Somehow this doesn't sound right.

--Jani

On Fri, 25 Nov 2005, Andrei Zmievski wrote:

Pierre Joye

20 years ago

On 11/26/05, Jani Taskinen <sniper@iki.fi> wrote:

>
>      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

Jani Taskinen

20 years ago

On Sat, 26 Nov 2005, Pierre Joye 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.

Ever heard about the magic omelette? (the one that existed without
breaking some eggs.. :)

--Jani

Pierre Joye

20 years ago

On Sat, 26 Nov 2005 15:07:15 +0200 (EET)
sniper@iki.fi (Jani Taskinen) wrote:

> On Sat, 26 Nov 2005, Pierre Joye 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

Sebastian Kugler

20 years ago

On 11/26/05, Jani Taskinen <sniper@iki.fi> wrote:

>
>      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

Bob Silva

20 years ago

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

Rasmus Lerdorf

20 years ago

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

Lester Caine

20 years ago

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.

Andrei Zmievski

20 years ago

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

On Nov 26, 2005, at 3:05 AM, Lester Caine wrote:

Christian Schneider

20 years ago

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

Pierre Joye

20 years ago

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

Scott MacVicar

20 years ago

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:

Ilia A.

20 years ago

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

Lukas Smith

20 years ago

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