Hey,
Just wanted to thank everyone who helped get PHP 5.1 out of the door
after a lot of efforts.
Special thanks to Steph who stepped up to make the upgrading guide
happen. I think this should become a standard for future PHP releases.
Also thanks to Ilia who picked up the last few rounds of PHP 5.1
release management to make it happen.
Well done everyone!
Andi
On Thu, 24 Nov 2005 16:15:04 -0800
andi@zend.com (Andi Gutmans) wrote:
Hey,
Just wanted to thank everyone who helped get PHP 5.1 out of the door
after a lot of efforts.
Special thanks to Steph who stepped up to make the upgrading guide
happen. I think this should become a standard for future PHP releases.
Also thanks to Ilia who picked up the last few rounds of PHP 5.1
release management to make it happen.Well done everyone!
Well Done Derick who did again what's the hell he wants.
If anyone can show me we agreed to put the crappy (yes crappy) new date
object ON by default in 5.1.0.
We agreed to not active it by default but let it under the experimental
#ifdef so Derick can still be lazy and use the same tree to maintain
his stuff.
I ask to stop the realease process, put all this Object date back in
the experimental #ifdef and roll 5.1 again.
--Pierre
Pierre wrote:
On Thu, 24 Nov 2005 16:15:04 -0800
andi@zend.com (Andi Gutmans) wrote:Hey,
Just wanted to thank everyone who helped get PHP 5.1 out of the door
after a lot of efforts.
Special thanks to Steph who stepped up to make the upgrading guide
happen. I think this should become a standard for future PHP releases.
Also thanks to Ilia who picked up the last few rounds of PHP 5.1
release management to make it happen.Well done everyone!
Well Done Derick who did again what's the hell he wants.
Pierre first of all I put the change in after a discussion with Derick
and a number of the while you were present btw. This was done to declare
the date class for "future" proofing and allow isolation of date
constants into a class, as is done for all new OO extensions.
If anyone can show me we agreed to put the crappy (yes crappy) new date
object ON by default in 5.1.0.
I'll pretend that by "crappy" you mean limited, which it is because all
the methods are disabled till 5.1.1 when we will enable them to allow a
extensive test cycle.
Ilia
On Thu, 24 Nov 2005 21:52:28 -0500
ilia@prohost.org (Ilia Alshanetsky) wrote:
^
Pierre first of all I put the change in after a discussion with Derick
and a number of the while you were present btw. This was done to
declare the date class for "future" proofing and allow isolation of
date constants into a class, as is done for all new OO extensions.
You cannot trust Derick about ext/date, sorry.
He did not respect our decisions since he started to work on the TZ
support and force anyone to use the new implementation in 5.1.x.
I never agreed to anything Derick did in 5.x but was forced to shut up
and let him put some stupid object inside a #ifdef, as far as this crap
was in a #ifdef, yes I would have said, fine, we have time until php6.
I'll pretend that by "crappy" you mean limited, which it is because
all the methods are disabled till 5.1.1 when we will enable them to
allow a extensive test cycle.
It is crap, I need one hour to do it and I doubt Derick has any good
plan about a real new Date object API in php
But this is not the problem, and you know that.
--Pierre
Pierre, I agree with you that it was a bad idea to turn on the stub date
class in the final release candidate giving people less than a week to
notice that we now conflict with a common pear class. We get all the
breakage and none of the benefits and nobody had any time to prepare the
pear side of the house for this. It also sucks that not a single pear
person tested the final RC and brought this up in the past week. There
is plenty of blame to go around here.
Longer term we have to be able to move functionality from pear to php.
That's one of the reasons pear exists. You can argue all you want over
whose date implementation is better. In the end code speaks. I know
you don't want to write any code unless you are sure it will be the
chosen implementation, and I don't think you ever managed to convince
everyone of the $date->m++ style of date manipulation. Not that this
really matters, in the end what matters is actual working code. We will
choose inferior working code over the perfect half-finished
implementation every time. So, if as you say it will only take you an
hour to implement, please do it so we can try it.
-Rasmus
Pierre wrote:
On Thu, 24 Nov 2005 21:52:28 -0500
ilia@prohost.org (Ilia Alshanetsky) wrote:^
Pierre first of all I put the change in after a discussion with Derick
and a number of the while you were present btw. This was done to
declare the date class for "future" proofing and allow isolation of
date constants into a class, as is done for all new OO extensions.You cannot trust Derick about ext/date, sorry.
He did not respect our decisions since he started to work on the TZ
support and force anyone to use the new implementation in 5.1.x.I never agreed to anything Derick did in 5.x but was forced to shut up
and let him put some stupid object inside a #ifdef, as far as this crap
was in a #ifdef, yes I would have said, fine, we have time until php6.I'll pretend that by "crappy" you mean limited, which it is because
all the methods are disabled till 5.1.1 when we will enable them to
allow a extensive test cycle.It is crap, I need one hour to do it and I doubt Derick has any good
plan about a real new Date object API in phpBut this is not the problem, and you know that.
--Pierre
On Thu, 24 Nov 2005 21:23:17 -0800
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
Pierre, I agree with you that it was a bad idea to turn on the stub
date class in the final release candidate giving people less than a
week to notice that we now conflict with a common pear class. We get
all the breakage and none of the benefits and nobody had any time to
prepare the pear side of the house for this. It also sucks that not
a single pear person tested the final RC and brought this up in the
past week. There is plenty of blame to go around here.
No, do not blame anyone but the one who commited the change and the one
who agreed.
Do not expect me neither to come up with any complaints, you know how
it ends when I try.
Longer term we have to be able to move functionality from pear to
php. That's one of the reasons pear exists. You can argue all you
want over whose date implementation is better. In the end code
speaks.
Wrong, in the end the one who commits without giving a single shit to
anyone wins, in this case, Derick. You can argue or say all rethoric
you have about code, commits, contribution or cooperation, facts are
that from day #1 the game is biased. If I did not ask and simply commit
my code in 5.0 branche, It would have gave two possible things:
- I lost my karma
- my code will be already in 5.0
Conclusion? I have to be an ass and do what I want, not what other
could expect.
I know you don't want to write any code unless you are sure
it will be the chosen implementation, and I don't think you ever
managed to convince everyone of the $date->m++ style of date
manipulation.
I proposed, I convinced people (read the archive if you do not
remember), but my way was too nice and slow for Derick.
Not that this really matters, in the end what matters
is actual working code. We will choose inferior working code over
the perfect half-finished implementation every time. So, if as you
say it will only take you an hour to implement, please do it so we
can try it.
What I say it is I need one hour to implement a brain dead OO interface
like this one around this API.
And what really matters anyway?
--Pierre
This one's a bit more annoying than usual ;)
It will basically break application that depends on the Date package
(eg. most of my code as DataObjects uses it internally).. Do we really
need another barrier to upgrade to 5.*?
Regards
Alan
On Thu, 24 Nov 2005 21:23:17 -0800
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:Pierre, I agree with you that it was a bad idea to turn on the stub
date class in the final release candidate giving people less than a
week to notice that we now conflict with a common pear class. We get
all the breakage and none of the benefits and nobody had any time to
prepare the pear side of the house for this. It also sucks that not
a single pear person tested the final RC and brought this up in the
past week. There is plenty of blame to go around here.No, do not blame anyone but the one who commited the change and the one
who agreed.Do not expect me neither to come up with any complaints, you know how
it ends when I try.Longer term we have to be able to move functionality from pear to
php. That's one of the reasons pear exists. You can argue all you
want over whose date implementation is better. In the end code
speaks.Wrong, in the end the one who commits without giving a single shit to
anyone wins, in this case, Derick. You can argue or say all rethoric
you have about code, commits, contribution or cooperation, facts are
that from day #1 the game is biased. If I did not ask and simply commit
my code in 5.0 branche, It would have gave two possible things:
- I lost my karma
- my code will be already in 5.0
Conclusion? I have to be an ass and do what I want, not what other
could expect.I know you don't want to write any code unless you are sure
it will be the chosen implementation, and I don't think you ever
managed to convince everyone of the $date->m++ style of date
manipulation.I proposed, I convinced people (read the archive if you do not
remember), but my way was too nice and slow for Derick.Not that this really matters, in the end what matters
is actual working code. We will choose inferior working code over
the perfect half-finished implementation every time. So, if as you
say it will only take you an hour to implement, please do it so we
can try it.What I say it is I need one hour to implement a brain dead OO interface
like this one around this API.And what really matters anyway?
--Pierre
This one's a bit more annoying than usual ;)
It will basically break application that depends on the Date package
(eg. most of my code as DataObjects uses it internally).. Do we really
need another barrier to upgrade to 5.*?
Yeah indeed, now I'll have a heap of a time when my customers want to
upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ...
didn't we have similar situation with PEAR::File and the SPL::File ? Which
was later renamed to FileObject so both could happily live side by side ?
(or is my memory failing me)
IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by
default)
Rasmus mentioned that no PEAR person tested the final RC and all that and
thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that
change done between the final RC and the official release ?
Regards
Helgi
Hello Helgi,
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.
One thing to discuss now is whether we want to put out 5.1.1 or even
5.1.0pl1 asap with Date in ext/Date renamed to something diferent.
best regards
marcus
Friday, November 25, 2005, 8:40:47 AM, you wrote:
This one's a bit more annoying than usual ;)
It will basically break application that depends on the Date package
(eg. most of my code as DataObjects uses it internally).. Do we really
need another barrier to upgrade to 5.*?
Yeah indeed, now I'll have a heap of a time when my customers want to
upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ...
didn't we have similar situation with PEAR::File and the SPL::File ? Which
was later renamed to FileObject so both could happily live side by side ?
(or is my memory failing me)
IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by
default)
Rasmus mentioned that no PEAR person tested the final RC and all that and
thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that
change done between the final RC and the official release ?
Regards
Helgi
Best regards,
Marcus
Marcus,
I have good news on this (I added both constants and function support!).
I will post the patch soon. There are still a few things that need to
be discussed, but right now the functionality is a huge step forward.
Best regards,
Jessie
Marcus Boerger wrote:
Hello Helgi,
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.One thing to discuss now is whether we want to put out 5.1.1 or even
5.1.0pl1 asap with Date in ext/Date renamed to something diferent.best regards
marcusFriday, November 25, 2005, 8:40:47 AM, you wrote:
This one's a bit more annoying than usual ;)
It will basically break application that depends on the Date package
(eg. most of my code as DataObjects uses it internally).. Do we really
need another barrier to upgrade to 5.*?Yeah indeed, now I'll have a heap of a time when my customers want to
upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ...
didn't we have similar situation with PEAR::File and the SPL::File ? Which
was later renamed to FileObject so both could happily live side by side ?
(or is my memory failing me)IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by
default)Rasmus mentioned that no PEAR person tested the final RC and all that and
thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that
change done between the final RC and the official release ?Regards
HelgiBest regards,
Marcus
Marcus Boerger wrote:
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.
Err, how are we supposed to prefix PEAR::Date?
PEAR_Date?
Date_Date?
Lala_Date?
I guess only the first one is somewhat valid proposal.
Anyways it makes absolute sense to use the best most clear class names
when we add functionality currently missing in PHP. Just as well it
makes sense for php core to do the same thing.
The problem is just that PEAR is not part of the php development cycle.
So whatever API we come up with is totally ignored by php core. This may
be because the PEAR API sucks. It may also be caused by the fact that
usually our implementation will probably be written for a previous PHP
version.
In a perfect world we would define an API, implement it in PEAR as a
testbed for interest and if we find its popular and there are
significant performance improvements to expect from an implementation in
C we take that API and implement it in C.
However I do not see this happening ever. So I do not see a point in
PEAR packages claiming away nice and clear names from php core. We
should either cooperate on the API level or just have php core superseed
PEAR stuff.
PEAR then goes and fixes whatever breakage occurs. What however would be
nice is some advance notice. And where is the entry in the upgrading
guide? Oh and for the record if there is a PEAR class by the name of
Date you can be sure that there is a class by the name of Date as well.
So in conclusion its needlessly messy. I am sure other projects than
PEAR also have a Date class. Maybe we need to teach our users (including
PEAR) that they should simply stick to prefixing everything with 3-4
letter combinations (maybe even offer a central place to register them,
like we should do in the PEAR channel listing -
http://pear.php.net/channels/).
regards,
Lukas
Hello Lukas,
Friday, November 25, 2005, 9:41:46 AM, you wrote:
Marcus Boerger wrote:
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.
Err, how are we supposed to prefix PEAR::Date?
PEAR_Date?
Date_Date?
Lala_Date?
I guess only the first one is somewhat valid proposal.
Anyways it makes absolute sense to use the best most clear class names
when we add functionality currently missing in PHP. Just as well it
makes sense for php core to do the same thing.
The problem is just that PEAR is not part of the php development cycle.
So whatever API we come up with is totally ignored by php core. This may
be because the PEAR API sucks. It may also be caused by the fact that
usually our implementation will probably be written for a previous PHP
version.
In a perfect world we would define an API, implement it in PEAR as a
testbed for interest and if we find its popular and there are
significant performance improvements to expect from an implementation in
C we take that API and implement it in C.
However I do not see this happening ever. So I do not see a point in
PEAR packages claiming away nice and clear names from php core. We
should either cooperate on the API level or just have php core superseed
PEAR stuff.
PEAR then goes and fixes whatever breakage occurs. What however would be
nice is some advance notice. And where is the entry in the upgrading
guide? Oh and for the record if there is a PEAR class by the name of
Date you can be sure that there is a class by the name of Date as well.
So in conclusion its needlessly messy. I am sure other projects than
PEAR also have a Date class. Maybe we need to teach our users (including
PEAR) that they should simply stick to prefixing everything with 3-4
letter combinations (maybe even offer a central place to register them,
like we should do in the PEAR channel listing -
http://pear.php.net/channels/).
That conclusion means stay with date in ext/date and have pear learn the
lesson by making the same mistake in core. Once again the only solution is
namespacing.
Best regards,
Marcus
Marcus Boerger wrote:
So in conclusion its needlessly messy. I am sure other projects than
PEAR also have a Date class. Maybe we need to teach our users (including
PEAR) that they should simply stick to prefixing everything with 3-4
letter combinations (maybe even offer a central place to register them,
like we should do in the PEAR channel listing -
http://pear.php.net/channels/).That conclusion means stay with date in ext/date and have pear learn the
lesson by making the same mistake in core. Once again the only solution is
namespacing.
indeed.
though this "mistake" applies to all of PEAR at this point ..
it effectively means we need to fix all of PEAR (which might be the
point where you start of from scratch, php5 only etc .. but this is a
topic for the pear mailinglists)
regards,
Lukas
Lukas Smith wrote:
Marcus Boerger wrote:
That conclusion means stay with date in ext/date and have pear learn the
lesson by making the same mistake in core. Once again the only
solution is
namespacing.indeed.
though this "mistake" applies to all of PEAR at this point ..
As has been pointed out before this isn't only a PEAR problem: Every
single application out there defining a Date class has to be changed if
the core adds a class with the same name.
Is this common? One of our running gags here is that every project ends
up adding its own set of date formating/conversion functions/classes at
some point. So unless people are prefixing all local classes there is a
rather good chance of having a class named Date in quite some projects.
Section [7] of CODING_STANDARDS Naming Conventions states that "The
class name should be prefixed with the name of the 'parent set'" but at
the same time lists "Curl" as good. Now my question is whether the
prefixing should be enforced (at least when a common name like Date is
used)?
Or
a) am I missing something
b) is it the core developers' opinion that core classes have the right
of way?
- Chris
Christian Schneider wrote:
As has been pointed out before this isn't only a PEAR problem: Every
single application out there defining a Date class has to be changed if
the core adds a class with the same name.
Defining classes/function with generic names will always be a problem as
they may end up conflicting with same constructs from other libraries or
PHP itself.
Is this common? One of our running gags here is that every project ends
up adding its own set of date formating/conversion functions/classes at
some point. So unless people are prefixing all local classes there is a
rather good chance of having a class named Date in quite some projects.
To design future proof code projects for the most part prefix all their
functions/classes to prevent naming conflicts.
Section [7] of CODING_STANDARDS Naming Conventions states that "The
class name should be prefixed with the name of the 'parent set'" but at
the same time lists "Curl" as good. Now my question is whether the
prefixing should be enforced (at least when a common name like Date is
used)?
It makes little sense to have a class called curl_curl, when it comes to
functions the coding standard applied and all functions have a prefix.
Ilia
Ilia Alshanetsky wrote:
Defining classes/function with generic names will always be a problem as
they may end up conflicting with same constructs from other libraries or
PHP itself.
Sure. But that doesn't change the fact that a class named date is
known to cause conflicts. And that the core has a higher
responsibility than any extension/library/package IMHO.
To design future proof code projects for the most part prefix all their
functions/classes to prevent naming conflicts.
Had a quick glance at Gallery2 because it was lying around and they
don't consistently prefix things. Most classes are prefixed but not all
of them. I'm inclined to believe that's the case for most popular
packages, let alone everything else.
It makes little sense to have a class called curl_curl, when it comes to
functions the coding standard applied and all functions have a prefix.
That's why I wrote "... (at least when a common name like date is
used)". While Curl is unique enough (although I'd rather have a longer
name for the sake of a uniform naming scheme) the name date will
definitely be causing problems. We all agree on that I think.
The question is only if you shift the responsibility to PHP developers
(a mere dozen people could decide to change it) or to PHP users
(thousands, not even aware of the issue).
Signing out of this thread with a plea for pragmatism,
- Chris
Hello Christian,
here again namespaces would be perfect. Given a lib that doesn't prefic
you'd simply d:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
regards
marcus
Friday, November 25, 2005, 2:14:10 PM, you wrote:
Ilia Alshanetsky wrote:
Defining classes/function with generic names will always be a problem as
they may end up conflicting with same constructs from other libraries or
PHP itself.
Sure. But that doesn't change the fact that a class named date is
known to cause conflicts. And that the core has a higher
responsibility than any extension/library/package IMHO.
To design future proof code projects for the most part prefix all their
functions/classes to prevent naming conflicts.
Had a quick glance at Gallery2 because it was lying around and they
don't consistently prefix things. Most classes are prefixed but not all
of them. I'm inclined to believe that's the case for most popular
packages, let alone everything else.
It makes little sense to have a class called curl_curl, when it comes to
functions the coding standard applied and all functions have a prefix.
That's why I wrote "... (at least when a common name like date is
used)". While Curl is unique enough (although I'd rather have a longer
name for the sake of a uniform naming scheme) the name date will
definitely be causing problems. We all agree on that I think.
The question is only if you shift the responsibility to PHP developers
(a mere dozen people could decide to change it) or to PHP users
(thousands, not even aware of the issue).
Signing out of this thread with a plea for pragmatism,
- Chris
Best regards,
Marcus
Marcus Boerger wrote:
here again namespaces would be perfect. Given a lib that doesn't prefix
you'd simply do:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
Only if newly introduced PHP core classes use a namespace too. You'll
have to use PHP\Date (or the like) if you want to avoid conflicts in
existing code. Plus maybe something like "import PHP\Date as Date" or
something along these lines if you want to avoid PHP\ in newly written
code where you know that there is no Date class yet.
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
Hi Chris,
Christian Schneider wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
I completely agree, and as I said before, I suspect the majority who are
asking for namespaces would agree with this also.
Regards,
Jessie
Jessie Hernandez wrote:
Hi Chris,
Christian Schneider wrote:
PS: I'd rather have : for namespaces with the whitespace restriction
for ? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
I completely agree, and as I said before, I suspect the majority who are
asking for namespaces would agree with this also.
Majority asking for namespaces != majority of php users.
Hello Gareth,
Gareth Ardron wrote:
Majority asking for namespaces != majority of php users.
How do you know? Have you conducted a poll?
Regards,
Jessie
Jessie Hernandez wrote:
Majority asking for namespaces != majority of php users.
How do you know? Have you conducted a poll?
Ok,fair enough, I haven't - but neither have you.
Until there's any degree of certainty as to how many users this impacts
upon I don't think you can say that one way is better.
Speaking personally, I prefer the : syntax to , and the whitespace
issue wouldn't impact me anyway - but it's not just about the people on
this list, is it? we've seen that just now with the date stuff.
Gareth Ardron schrieb:
Jessie Hernandez wrote:
Majority asking for namespaces != majority of php users.
How do you know? Have you conducted a poll?
My guess:
80.0% "What's a namespace?"
17.0% "I don't care."
2.9% "Yes please, weren't they already promised for 5.0 "
0.1% "Oh no. And could you please remove classes and all
the other annoying OOP stuff."
Which leaves me with 99.9% of the userbase being fine with introducing
namespaces (if a standard php.ini setting ensures that all core stuff is
automatically imported if you don't disable it).
OLLi
Hello Gareth,
Saturday, November 26, 2005, 2:22:15 AM, you wrote:
Jessie Hernandez wrote:
Hi Chris,
Christian Schneider wrote:
PS: I'd rather have : for namespaces with the whitespace restriction
for ? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
I completely agree, and as I said before, I suspect the majority who are
asking for namespaces would agree with this also.
Majority asking for namespaces != majority of php users.
Exactly! And i'd say that people wanting namespaces are the minority.
Best regards,
Marcus
what are the options for the seperator? i have not been watching this topic
but is the . out of the question?
namespace.class->method();
--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
1-802-671-2021
codebowl@gmail.com
Hello Joseph,
then why start this discussion over again. Read first, think second. Third
write if there is still a need. Regarding second ever used the '.' operator
in PHP? And you are Zend certified, damn the test is to easy :-)
marcus
Saturday, November 26, 2005, 1:48:35 PM, you wrote:
what are the options for the seperator? i have not been watching this topic
but is the . out of the question?
namespace.class->method();
--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
1-802-671-2021
codebowl@gmail.com
Best regards,
Marcus
Marcus Boerger schrieb:
And i'd say that people wanting namespaces are the minority.
The majority of people using PHP does not know what namespaces are
because they were never in a situation in which they needed them, hence
they do not "want" them.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Marcus Boerger schrieb:
And i'd say that people wanting namespaces are the minority.
The majority of people using PHP does not know what namespaces are
because they were never in a situation in which they needed them, hence
they do not "want" them.
I know pretty well now what they are and I still don't need or want them.
You should always prefix anyway. :)
--Jani
Sebastian Bergmann schrieb:
Marcus Boerger schrieb:
And i'd say that people wanting namespaces are the minority.
The majority of people using PHP does not know what namespaces are
because they were never in a situation in which they needed them, hence
they do not "want" them.
No, there are simply three groups of people: One consisting of those not
knowing about namespaces and those who don't care about them. They have
no opinion on this and if they are implemented so they won't notice the
difference until they try to use them, they're fine and don't have to be
considered here.
Then there are two groups who are well aware of the subject and they are
split into the pro- and contra evangelists. The pro people used to come
up with the "kinda-forbidden" word "enterprise-ready", which seems to be
disliked throughout the PHP community. Since the release of 5.1.0 they
can simply switch their argumentation to "The whole 'date' thingie
wouldn't have happened with namespaces!". The contra people throw in the
abbreviation KISS and see unnecessary complexity moving into the language.
Well, couldn't the namespaces have a "mode" where the namespace is
automatically prefixed to everything inside it (PEAR:Date => PEAR_Date)
so not using the "import" statement and using this mode would give the
contra fraction the same behaviour they want to retain?
OLLi
Marcus Boerger wrote:
here again namespaces would be perfect. Given a lib that doesn't prefix
you'd simply do:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)Only if newly introduced PHP core classes use a namespace too. You'll have
to use PHP\Date (or the like) if you want to avoid conflicts in existing
code. Plus maybe something like "import PHP\Date as Date" or something
along these lines if you want to avoid PHP\ in newly written code where
you know that there is no Date class yet.PS: I'd rather have : for namespaces with the whitespace restriction for ?
a:x : b:y than the confusing (escaping characters outside of a string?)
backslash.
- Chris
Have I missed something or what? Why not use C++ style for namespaces?
backslash is really ugly!
Nuno
Hello Christian,
Saturday, November 26, 2005, 1:42:07 AM, you wrote:
Marcus Boerger wrote:
here again namespaces would be perfect. Given a lib that doesn't prefix
you'd simply do:
namespace LibNameHere { reqire "some_lib_include"; }
and be done...wohooo :-)
Only if newly introduced PHP core classes use a namespace too. You'll
have to use PHP\Date (or the like) if you want to avoid conflicts in
existing code. Plus maybe something like "import PHP\Date as Date" or
something along these lines if you want to avoid PHP\ in newly written
code where you know that there is no Date class yet.
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
And kill trillions of php scripts, how funny. Think before writing.
Best regards,
Marcus
Hello Christian,
Saturday, November 26, 2005, 1:42:07 AM, you wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.And kill trillions of php scripts, how funny. Think before writing.
It may well be impractical to code for all I know, but surely this is
not technically impossible? As of now I really don't think ? a:x:b:y
works anyway, so what is going to be broken by requiring ? a:x : b:y
when the ternary operator is used with namespaced expressions?
I do think just about anything is preferable to \ as namespace
separator. Be imaginative; it can be two characters, like :>. Unless
that has some collision with the > operator that I cannot see, or there
is no two character separator that is less generally undesirable than .
I think three character separators would be taking the search too far,
though :)
Matt
Marcus Boerger wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.And kill trillions of php scripts, how funny. Think before writing.
From Jessie's statements I was assuming that ONLY in the ternary case
you would need whitespaces/parens to disambiguate the expression. That
would break way less PHP scripts than, say, a core Date class ;-)
If that's not the case then the situation is different. My bad for not
getting around to try his patch, so I still don't know. But there's
still no need for a blow below the belt, I am thinking before I write.
Could everybody please move on now?
That means can someone who (according to the PHP developers) is in
charge decide what's going to happen regarding the date class? Because
everything else has time but date needs a decision now.
Thanks,
- Chris
Hi Chris,
Christian Schneider wrote:
From Jessie's statements I was assuming that ONLY in the ternary case
you would need whitespaces/parens to disambiguate the expression. That
would break way less PHP scripts than, say, a core Date class ;-)
Yes, this is true, but still, I wouldn't be surprised if many people use
code such as "$x = $y?CONSTANT1:CONSTANT2;" right now, so by introducing
this change, which should have absolutely no BC issues at all, you may
potentially break scripts, which is something I'd rather not do. I might
have a solution for this though, just give me some time to implement.
For now, we can forget about namespace constants (they're not critical,
anyways).
Regards,
Jessie
Lukas Smith wrote:
obviously one problem is that PEAR does ignore coding standards.
Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces
asap.Err, how are we supposed to prefix PEAR::Date?
To be on the safe side: Net_PHP_PEAR_Date;) "Underscores are more
namespace than anyone will ever need".
Sebastian
Hello Helgi,
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.One thing to discuss now is whether we want to put out 5.1.1 or even
5.1.0pl1 asap with Date in ext/Date renamed to something diferent.
No, as this breaks backwards compability. I have code written for this
and that is going to be released. If the class constants are removed,
you will break code that is out there. There were similar reasons why
Wez didn't want to change the odd PDO method because people were running
it production while PDO was not even beta - which is fine. But you can
definitely not change code in a released version.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Fri, 25 Nov 2005 10:49:24 +0100 (CET)
derick@php.net (Derick Rethans) wrote:
Hello Helgi,
obviously one problem is that PEAR does ignore coding standards.
Classes should be prefixed in both pear and core. And neither Date
nor File is in any way prefixed. In th end all we see here is that
we want namespaces asap.One thing to discuss now is whether we want to put out 5.1.1 or even
5.1.0pl1 asap with Date in ext/Date renamed to something diferent.No, as this breaks backwards compability. I have code written for
this and that is going to be released. If the class constants are
removed, you will break code that is out there. There were similar
reasons why Wez didn't want to change the odd PDO method because
people were running it production while PDO was not even beta - which
is fine. But you can definitely not change code in a released version.
I think you are either kidding or living in a dream.
You keep doing what you want, do not inform us about what you do (and
do not say anything in commit messages).
This release is a mistake and again you are responsible for that.
Assume your wrong decisions once.
--Pierre
Derick,
you will break code that is out there.
do you have an idea how much code is "out there" that has classes named "Date"?
But you can
definitely not change code in a released version.
Above all, you can definitely not introduce new classes in RC6!
And this date class doesn't even seem to provide any functionality, so
that there would be an incentive (or even possibility) to migrate
projects using PEAR::Date to the new Date class. Why did this class
have to be crippled (i. e. deactivating its methods) BUT incorporated
in 5.1 and why not before RC6?
-- Sebastian
Derick,
you will break code that is out there.
do you have an idea how much code is "out there" that has classes
named "Date"?
No, I have no numbers, but there are definitely people who used that
name out there (besides PEAR). PHP 5.1 does come with other changes in
behavior though, which are all meant in the upgrade notes. Included here
is the issue with the date class.
(I know this only works in an ideal world:) Users should always evaluate
if they can upgrade to the latest PHP version (x. or .y.) to see if
there is any change in behavior, therefore it shouldn't be that much of
a problem for people writing good applications. ISPs should know better
than to upgrade immediately.
Above all, you can definitely not introduce new classes in RC6!
It was oversighted, it should indeed have been done before rc1 (or rc2).
And this date class doesn't even seem to provide any functionality, so
that there would be an incentive (or even possibility) to migrate
projects using PEAR::Date to the new Date class. Why did this class
have to be crippled (i. e. deactivating its methods) BUT incorporated
in 5.1 and why not before RC6?
It has class constants, so there is (some) functionality. Previously
the constants were "DATE_ISO8601" and now they are date::ISO8601, this
is something that I use in my code currently - this code is about to be
released to the public. And if it was for me, this class would have
had functionality and it has been ifdef'ed out in CVS for about 5 months
now because it could stall the release.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Sebastian Kugler schrieb:
Derick,
you will break code that is out there.
do you have an idea how much code is "out there" that has classes named "Date"?
Raising hand
And I have it in installations I don't even maintain anymore.
How kind of Derick to probably get someone several working hours when
these customers decide to go upgrade to 5.1.
OLLi
No, as this breaks backwards compability. I have code written for this
and that is going to be released. If the class constants are removed,
you will break code that is out there. There were similar reasons why
Wez didn't want to change the odd PDO method because people were running
it production while PDO was not even beta - which is fine. But you can
definitely not change code in a released version.
Derick, the Date class is in "a released version" because you
sneaked it in through the backdoor. Activating a class in
the final RC was obviously wrong and you are very well aware
of the fact. Don't try to cover up now.
- Sascha
No, as this breaks backwards compability. I have code written for this
and that is going to be released. If the class constants are removed,
you will break code that is out there. There were similar reasons why
Wez didn't want to change the odd PDO method because people were running
it production while PDO was not even beta - which is fine. But you can
definitely not change code in a released version.Derick, the Date class is in "a released version" because you sneaked it in through the backdoor. Activating a class in the final RC was obviously wrong and you are very well aware of the fact. Don't try to cover up now.
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1.
This code has been in CVS for about 5 months, but people didn't want to
have it enabled as they didn't want to stall the release. The idea was
to put it into 5.1.1 then. That is fine, but I think it's not fair to
blame me for not having being allowed to put my code in there and thus
creating the current problems.
Besides that, using "Date" and "Timezone" as classnames are the most
sensible names for those classes and I do not think we should have
change that.
regards,
Derick
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1.
Then I have to ask both of you: why is there no mentioning in
the release notes or the upgrading guide regarding "Date"
being reserved for PHP now?
The language/base library might want to reserve certain
simple classnames for itself. That is its right.
But: Doing so in a minor release is absolutely bad timing.
It gets worde because there apparently has been _no_
documentation of the fact at all. How shall our users
prepare themselves appropiately?
I move that the class is renamed for the time being as to not
conflict with existing codebases, and release 5.1.1
expediently.
- Sascha
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1.Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now?
I thought it was actually, as I saw somebody quoting this.
It gets worde because there apparently has been _no_ documentation of the fact at all. How shall our users prepare themselves appropiately?
This is why I petition to ammend the release notes ASAP.
I move that the class is renamed for the time being as to not conflict with existing codebases, and release 5.1.1 expediently.
Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break my code ;-)
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break my code ;-)
Why does it have to be in core php in order for your code to run smoothly?
I'd like to remind you that if was you who proposed some weeks ago
that people should patch and maintain their own PHP if they don't want
their apps to break because of the reference fix in 4.4.0. So why
don't you just patch your own PHP for that purpose? Because you're a
core developer?
I really appreciate the huge amount of work you and others put in PHP.
But this is really getting a bit weird now... BC breaks in bugfix
releases, one BC break in RC5 (curly braces), the next one in RC6...
-- Sebastian
I'd like to remind you that if was you who proposed some weeks ago
that people should patch and maintain their own PHP if they don't want
their apps to break because of the reference fix in 4.4.0. So why
don't you just patch your own PHP for that purpose? Because you're a
core developer?
No, because that was a bug fix which people still don't get.
regards,
Derick
So why
don't you just patch your own PHP for that purpose? Because you're a
core developer?No, because that was a bug fix which people still don't get.
At least I got it and we swallowed that bitter pill in 4.4.0 that lots
of our OO PHP client projects broke unadvertedly with the bugfix
release.
But as you imply, the date issue is not a bugfix so there is even
less an acceptable reason to introduce it in RC 6!
If it was oversighted before RC 1, a professional process should
prevent it from being incorporated in 5.1 at all. What sense does it
make to test an RC 1 if you can't be sure that PHP won't introduce the
major BC breaks before RC 5? ;-)
If it was oversighted before RC 1, a professional process should
prevent it from being incorporated in 5.1 at all. What sense does it
make to test an RC 1 if you can't be sure that PHP won't introduce the
major BC breaks before RC 5? ;-)
We were already planning to put it in there, it was just forgotten. We
are not machines.
Derick
Derick Rethans wrote:
I move that the class is renamed for the time being as to not conflict with existing codebases, and release 5.1.1 expediently.
I second that. Otherwise 5.1 is a dead branch lots of people won't
update to.
Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break my code ;-)
Does that mean your code is more important than all the lines of code
out there? You must be kidding.
And as you stated yourself your code hasn't even been released yet.
Besides that, using "Date" and "Timezone" as classnames are the most
sensible names for those classes and I do not think we should have
change that.
By the same logic the function file_get_contents() could be called
get(). Using generic names for core functionality in the global name
space is a bad thing, no matter how convenient the name might be. That's
a lesson PHP has learned for function names quite a while ago, let's not
repeat the same mistake for class names.
And let's undo the slip before more harm is done.
- Chris
Does that mean your code is more important than all the lines of code
out there? You must be kidding. And as you stated yourself your code
hasn't even been released yet.
I didn't say that my code is more important, but if we don't get the
date class now, we will get it in 5.1.1 and then break your code - so
that doesn't really matter. THe only correct solution is to start
prefixing the pear date class, as that needs to be done in the long run
anyway.
Besides that, using "Date" and "Timezone" as classnames are the most
sensible names for those classes and I do not think we should have change
that.By the same logic the function
file_get_contents()could be called get().
?
Using generic names for core functionality in the global name space is a bad
thing, no matter how convenient the name might be. That's a lesson PHP has
learned for function names quite a while ago, let's not repeat the same
mistake for class names.
No no, the core reserves the right to name whatever they want, it's the
userland code that is responsible for prefixing their classes.
Derick
Derick Rethans wrote:
Using generic names for core functionality in the global name space
is a bad
thing, no matter how convenient the name might be. That's a lesson
PHP has
learned for function names quite a while ago, let's not repeat the same
mistake for class names.No no, the core reserves the right to name whatever they want, it's
the userland code that is responsible for prefixing their classes.
True, but where part of the PHP project has already adopted that name,
doesn't it make sense to assume that they have a first priority to this.
This seems to fall back to the discussion a few months back about how
much BC breakage people wanted to cause in 5.1/6 in any case. I thought
this was resolved back then, but evidently not.
It'd seem to me that there's two options - just say that there'll be
breakage[0] like this throughout the 5/5.1 release process and don't get
anybody moving to it or to keep major breaking for major revisions - the
way every other largescale opensource project works (and does so for a
damn good reason).
I'd personally far rather that such a break came in 5.1 over 5.1.1,
though I still don't think a change which has such a major impact over
such a large portion of the userbase is a good plan for a minor release
(much less a maintainance release like 5.1.1); after all, there's been
some 259,000 downloads of pear's date class and I'd argue there's a
substantial amount of developers with their own date class outside of
that group. You're effectively talking about hitting 300,000-500,000
developers with a massive change on a minor release. You talk about
doing things the 'right' way often - well that's just plain wrong.
[0] Ok, I know it's not really breaking anything within php - but it's
breaking a lot of apps.
Derick Rethans wrote:
I didn't say that my code is more important, but if we don't get the
date class now, we will get it in 5.1.1 and then break your code - so
You're stating this like a fact. Date can be renamed, there's nothing
sacro-sanct about this class.
Just to illustrate some question which could be raised to weaken your
point that Date is the one and only name for that class:
Why does it include time as well, shouldn't it be Datetime (a la SQL)?
Is it going to be the only class in ext/date (no, there is already
timezone)? => Shouldn't it be Date_Timezone and Date_Date/Date_Datetime
then?
By the same logic the function
file_get_contents()could be called get().?
Because I personally feel that get() would be the right name for it the
same way you feel Date is the right name for your class.
No no, the core reserves the right to name whatever they want, it's the
userland code that is responsible for prefixing their classes.
Is that why function names were prefixed? Or __get?
You sure have the right to introduce whatever you want but is it also
smart to insist on a specific name if you could easily avoid conflicts?
PHP moved on from "what is legal" to "what is right" a long time ago IMHO.
As soon as we have separate namespaces for core/application classes we
can talk how to resolve issues like that again but for now I'd highly
appreciate if you'd take a more conservative approach.
Cheers,
- Chris
Just to illustrate some question which could be raised to weaken your point
that Date is the one and only name for that class:
Why does it include time as well, shouldn't it be Datetime (a la SQL)? Is it
going to be the only class in ext/date (no, there is already timezone)? =>
Shouldn't it be Date_Timezone and Date_Date/Date_Datetime then?
No, why should it? We reserve the right to use whatever name we want in
the core (although prefixing internal classes with Pear would be sneaky ;-) )
No no, the core reserves the right to name whatever they want, it's the
userland code that is responsible for prefixing their classes.Is that why function names were prefixed? Or __get?
No, that's for logic's sense.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
Just to illustrate some question which could be raised to weaken your point
that Date is the one and only name for that class:
Why does it include time as well, shouldn't it be Datetime (a la SQL)? Is it
going to be the only class in ext/date (no, there is already timezone)? =>
Shouldn't it be Date_Timezone and Date_Date/Date_Datetime then?No, why should it? We reserve the right to use whatever name we want in
the core (although prefixing internal classes with Pear would be sneaky ;-) )
Who is "we"? People bent on making life as difficult as possible for PHP
users? I'm sure you're not talking about the broad range of people here
and I would appreciate if you didn't make it sound like most of PHP
developers are behind your methods and attitude here.
Sneaking in date class like that is really unacceptable, and 5.1.1 with
it removed should be released ASAP.
Edin
Derick,
I am not sure where you came up with this idea, but it's patently
untrue. Core and userland have to co-exist, and that means cooperation,
not blatant disregard for thousands of users out there. Unless you're
speaking only for yourself, and in that case, I hope your upcoming
vacation is a good one, cause you need to de-stress, or something.
- Andrei
No, why should it? We reserve the right to use whatever name we want in
the core (although prefixing internal classes with Pear would be
sneaky ;-) )No no, the core reserves the right to name whatever they want, it's
the
userland code that is responsible for prefixing their classes.Is that why function names were prefixed? Or __get?
No, that's for logic's sense.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1.Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now?I thought it was actually, as I saw somebody quoting this.
There is no mentioning of "PHP reserves the classname "Date"
starting with PHP 5.1. Audit your source code for the use of
that classname before upgrading."
This is why I petition to ammend the release notes ASAP.
You cannot amend the release announcement. It is nice that
we have an upgrade guide, but something as fundamental as new
reserved identifiers/classnames belongs into the
announcement.
Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break my code ;-)
I am sure you see the flaw in that argument yourself without
me having to point it out.
- Sascha
Hello Sascha,
Friday, November 25, 2005, 1:36:11 PM, you wrote:
There is no mentioning of "PHP reserves the classname "Date" starting with PHP 5.1. Audit your source code for the use of that classname before upgrading."
This is why I petition to ammend the release notes ASAP.
Sasch stay serious, we don't mention every new function or class name. And
if we would people would require a new list that is shorter becasue nobody
would read the full list. And at that point we would be at the beginning
what to put in the shorter notes......
Best regards,
Marcus
Derick,
That's a pretty selfish point of view you have there. So, as long as
your code works, screw everyone else?
- Andrei
Yes, and that will break code again as I just explained to Sebastian
Kettler. And it will break my code ;-)
Sascha Schumann wrote:
Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now?
There are notes in the guide, and I quote:
"
Note that the new Date class exists at this point purely to allow the
core date extension to adhere to the above convention, although extended
functionality is planned for the the class in the future.
"
Ilia
Sascha Schumann wrote:
Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now?There are notes in the guide, and I quote:
I've seen that text. It is hidden at the end of a paragraph
not related to the topic at all (something about class
constants). As such it is totally inadequate. There should
be a prominent point in the release announcement about
reserved symbols.
- Sascha
Sascha Schumann wrote:
I've seen that text. It is hidden at the end of a paragraph not related to the topic at all (something about class constants). As such it is totally inadequate. There should be a prominent point in the release announcement about reserved symbols.
Does this include anytime a new function/class is added we need to make
a prominent notice about since it reserves some name space?
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?
Ilia
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
I've seen that text. It is hidden at the end of a paragraph
not related to the topic at all (something about class
constants). As such it is totally inadequate. There should
be a prominent point in the release announcement about
reserved symbols.Does this include anytime a new function/class is added we need to make
a prominent notice about since it reserves some name space?Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?
To start with we remove the Date class and release 5.1.1 immediately.
Then we come back and discuss how to solve the actual problem in a
proper manner and in a proper forum (here).
Edin
On Fri, 25 Nov 2005 08:21:42 -0500
ilia@prohost.org (Ilia Alshanetsky) wrote:
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come
up with?
It is the only fix, breaking Derick's code is the bigest problem we
will have.
The fact is we should have done that in php6, there we are "allowed" to
do it and our userbase will have plenty of times to be warned or update
their codes.
--Pierre
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?
There is no suitable alternative for the 5.1 branch.
- Sascha
Sascha Schumann wrote:
There is no suitable alternative for the 5.1 branch.
Assuming that is the case we need to either rename ext/date's date class
or ifdef it away. If we rename it, what to date_ex, DateTime, phpDate,
something else?
Ilia
On Fri, 25 Nov 2005 08:43:43 -0500
ilia@prohost.org (Ilia Alshanetsky) wrote:
Sascha Schumann wrote:
There is no suitable alternative for the 5.1 branch.Assuming that is the case we need to either rename ext/date's date
class or ifdef it away. If we rename it, what to date_ex, DateTime,
phpDate, something else?
Again, #ifdef it away (or if it is only up to me, just remove the whole
related code) as it was the case until now.
Give us the time to solve this problem in a normal and sane way for
php6. Normal and sane means discussions and approbations around this
list.
--Pierre
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
There is no suitable alternative for the 5.1 branch.
Assuming that is the case we need to either rename ext/date's date class
or ifdef it away. If we rename it, what to date_ex, DateTime, phpDate,
something else?
ifdef it away and throw a nice (strict?) notice when people use basic
class names as 'Date', 'Db', 'File' etc. This silently makes the
namespace reserved for feature core classes that might have that name.
David
Hello Ilia,
to me PhpDate would be nice :-))
Friday, November 25, 2005, 2:43:43 PM, you wrote:
Sascha Schumann wrote:
There is no suitable alternative for the 5.1 branch.
Assuming that is the case we need to either rename ext/date's date class
or ifdef it away. If we rename it, what to date_ex, DateTime, phpDate,
something else?
Does this include anytime a new function/class is added we need to make
a prominent notice about since it reserves some name space?
Yes of course, especially if it's such an obvious name like "date".
As opposed to some statements on this list, I would argue that the
global namespace should be reserved for ("owned by") those who write
PHP applications and not for the PHP core developers.
Especially for a language like PHP, where everything is in the core
and no namespaces or packages exist.
How am I supposed to know what class names PHP decides to capture tomorrow?
So, assuming your old applications are totally future proof is naive.
Well, that's exactly what my customers expect from the software we
develop for them. And btw, maybe it's part of what "enterprise-ready"
is about. I admit that 100% future proofness can never be achieved.
But every break of it it should be carefully considered. And I'm
pretty sure that in the end, companies will go for the platform that
offers the best future proofness of their applications.
Regards
Sebastian
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
I've seen that text. It is hidden at the end of a paragraph not related to the topic at all (something about class constants). As such it is totally inadequate. There should be a prominent point in the release announcement about reserved symbols.Does this include anytime a new function/class is added we need to make
a prominent notice about since it reserves some name space?Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?
I don't think it ties our hands. The current problem is that people had
about a week to prepare for this and the commit message of:
"Moved date constants into the date class, they all class constants now."
didn't exactly trigger people to run out to fix this. I was under the
impression that this date class was ifdef'ed out and although I should
have realized that it is impossible to move the date constants to class
constants without also enabling the class, I didn't think of it when I
saw this commit roll by. So I feel somewhat tricked by this and I don't
like that. I know it wasn't an intentional thing, but Derick's view
that "Gotcha! It's in 5.1.0 now, so you can't change it" doesn't sit
well with me either.
As I stated before, core PHP does reserve the right to pick up the most
obvious keywords as we come up with new functionality, and I think we
should have a date class, but we should do it in an orderly manner and
give people some time to migrate to something that actually makes sense.
At this point I don't really care if we roll it back or give it some
obscure temporary name like date_ex which we can use as a temporary
placeholder while we work out what this class should look like. Despite
all of Pierre's hot air, he does actually have some good ideas in
pecl/date that should be considered and Derick's timezone code appears
to be solid at least from the parts of it I have used so far. So let's
just take a deep breath here, fix the naming clash with pear and give
them a chance to prefix their stuff and provide a sane migration path
for users and then come up with a sensible plan for what the PHP date
class should look like and work with the pear guys to make sure they can
actually use this new class in their migration path.
-Rasmus
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then
took advantage of the fact that release managers changed to enable
his class. Doesn't leave a good taste in my mouth and it shouldn't
happen again in future.
Andi
At 08:31 AM 11/25/2005, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
I've seen that text. It is hidden at the end of a paragraph not related to the topic at all (something about class constants). As such it is totally inadequate. There should be a prominent point in the release announcement about reserved symbols.Does this include anytime a new function/class is added we need to make
a prominent notice about since it reserves some name space?
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?I don't think it ties our hands. The current problem is that people
had about a week to prepare for this and the commit message of:"Moved date constants into the date class, they all class constants now."
didn't exactly trigger people to run out to fix this. I was under
the impression that this date class was ifdef'ed out and although I
should have realized that it is impossible to move the date
constants to class constants without also enabling the class, I
didn't think of it when I saw this commit roll by. So I feel
somewhat tricked by this and I don't like that. I know it wasn't an
intentional thing, but Derick's view that "Gotcha! It's in 5.1.0
now, so you can't change it" doesn't sit well with me either.As I stated before, core PHP does reserve the right to pick up the
most obvious keywords as we come up with new functionality, and I
think we should have a date class, but we should do it in an orderly
manner and give people some time to migrate to something that
actually makes sense.At this point I don't really care if we roll it back or give it some
obscure temporary name like date_ex which we can use as a temporary
placeholder while we work out what this class should look
like. Despite all of Pierre's hot air, he does actually have some
good ideas in pecl/date that should be considered and Derick's
timezone code appears to be solid at least from the parts of it I
have used so far. So let's just take a deep breath here, fix the
naming clash with pear and give them a chance to prefix their stuff
and provide a sane migration path for users and then come up with a
sensible plan for what the PHP date class should look like and work
with the pear guys to make sure they can actually use this new class
in their migration path.-Rasmus
BTW, just to clarify, I am not against a Date class (whatever its
name) in the long run but I think it'd probably be a combination of
work Derick, Pierre and new contributions.
Andi
At 09:17 AM 11/25/2005, Andi Gutmans wrote:
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then
took advantage of the fact that release managers changed to enable
his class. Doesn't leave a good taste in my mouth and it shouldn't
happen again in future.Andi
At 08:31 AM 11/25/2005, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
Sascha Schumann wrote:
I've seen that text. It is hidden at the end of a paragraph not related to the topic at all (something about class constants). As such it is totally inadequate. There should be a prominent point in the release announcement about reserved symbols.Does this include anytime a new function/class is added we need to make
a prominent notice about since it reserves some name space?
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?I don't think it ties our hands. The current problem is that
people had about a week to prepare for this and the commit message of:"Moved date constants into the date class, they all class constants now."
didn't exactly trigger people to run out to fix this. I was under
the impression that this date class was ifdef'ed out and although I
should have realized that it is impossible to move the date
constants to class constants without also enabling the class, I
didn't think of it when I saw this commit roll by. So I feel
somewhat tricked by this and I don't like that. I know it wasn't
an intentional thing, but Derick's view that "Gotcha! It's in
5.1.0 now, so you can't change it" doesn't sit well with me either.As I stated before, core PHP does reserve the right to pick up the
most obvious keywords as we come up with new functionality, and I
think we should have a date class, but we should do it in an
orderly manner and give people some time to migrate to something
that actually makes sense.At this point I don't really care if we roll it back or give it
some obscure temporary name like date_ex which we can use as a
temporary placeholder while we work out what this class should look
like. Despite all of Pierre's hot air, he does actually have some
good ideas in pecl/date that should be considered and Derick's
timezone code appears to be solid at least from the parts of it I
have used so far. So let's just take a deep breath here, fix the
naming clash with pear and give them a chance to prefix their stuff
and provide a sane migration path for users and then come up with a
sensible plan for what the PHP date class should look like and work
with the pear guys to make sure they can actually use this new
class in their migration path.-Rasmus
Hello Andi,
Friday, November 25, 2005, 6:43:25 PM, you wrote:
BTW, just to clarify, I am not against a Date class (whatever its
name) in the long run but I think it'd probably be a combination of
work Derick, Pierre and new contributions.
Yes from my point of view there could coexist a base class that supports all
basic features and an advanced class happily in one php universe and there is
even place for peoples own stuff and of course a PEAR_Date (or however named
too).
The base class could for instance have methods that return iterators for date
ranges, say DateRange or DateIterator. That would allow pretty neat code and
ease the pain in heavy date dependant code very much. (Actually something i
proposed right from the first moment i heared of pecl/date or ext/date).
Best regards,
Marcus
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then took
advantage of the fact that release managers changed to enable his class.
Doesn't leave a good taste in my mouth and it shouldn't happen again in
future.Andi
Just to clarify, it was Ilia who enabled the class, but just to move the
constants there. All methods are still disabled.
As I stated before, core PHP does reserve the right to pick up the most
obvious keywords as we come up with new functionality, and I think we
should have a date class, but we should do it in an orderly manner and
give people some time to migrate to something that actually makes sense.-Rasmus
Right! And changing a class name from a PHP program takes just a few
seconds..
Nuno
On Fri, 25 Nov 2005 19:49:04 -0000
nlopess@php.net ("Nuno Lopes") wrote:
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then
took advantage of the fact that release managers changed to enable
his class. Doesn't leave a good taste in my mouth and it shouldn't
happen again in future.Andi
Just to clarify, it was Ilia who enabled the class, but just to move
the constants there. All methods are still disabled.
He did it on Derick's demand. Ilia's mistake was to trust him. As Andi
did too.
As I stated before, core PHP does reserve the right to pick up the
most obvious keywords as we come up with new functionality, and I
think we should have a date class, but we should do it in an
orderly manner and give people some time to migrate to something
that actually makes sense.-Rasmus
Right! And changing a class name from a PHP program takes just a few
seconds..
Wrong, you have to first test, change and retest. Some cannot be
changed for obvious reasons, like pear::date, if you do not understand
that, feel free to ask me why on irc, prv.
--Pierre
Just to clarify, it was Ilia who enabled the class, but just to move
the constants there. All methods are still disabled.He did it on Derick's demand. Ilia's mistake was to trust him. As Andi
did too.
Since when do you think for Ilia? Your statement is false, you weren't
there so why the f**k are you commenting on it like this? I did not
suggest to make it class constants!
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
I must say that I feel deceived by this.
Derick and I agreed that this won't be enabled for 5.1, and he then took
advantage of the fact that release managers changed to enable his class.
Doesn't leave a good taste in my mouth and it shouldn't happen again in
future.
That is untrue! The class' code is not enabled (there are no methods),
that was never the idea. Ilia suggested to make class constants afaik
following PDO with this. THere was never any idea of enabling the whole
class for PHP 5.1.0.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Guys,
simply because the crew that actually develops php and tests it a lot
before a release obviously doesn't use PEAR. And given the fact that pear
was dropped from the main releases because it didn't fit into it
functionality and compatibility wise anyway i see no reason to change this
than pear changing or pear testing. And yes it was late but it was an
oversight. And yes we don't usually change in between RCs. But yes we do if
we find that something was done wrong. And anything even a missing feature
or change is a failure.
And it doesn't help to shout or whine along.
So right now we should simply all relax a bit and find a solution in a
constructive discussion not in pissing at each other.
Take the lessen and test next time. All of us. All th ecode they want to
use.
And as Andi stated. PHP 5.1 is a lot of very good work. Anybody who
participated in its making should be proud.
Anybody who gave a 'shit' up until now may stay with php 4 or 5.0 if you ask
me :-)
I for one like 5.1 and will finally move from 4.* to 5.* on all servers i
can - at least my private one.
p.s.: Regarding pear if pear is so important it would be nice if pear was at
least 5.0 code. All of it.
Friday, November 25, 2005, 11:49:50 AM, you wrote:
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1.
Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding "Date" being reserved for PHP now?
The language/base library might want to reserve certain simple classnames for itself. That is its right.
But: Doing so in a minor release is absolutely bad timing. It gets worde because there apparently has been _no_ documentation of the fact at all. How shall our users prepare themselves appropiately?
I move that the class is renamed for the time being as to not conflict with existing codebases, and release 5.1.1 expediently.
- Sascha
Best regards,
Marcus
Marcus Boerger wrote:
p.s.: Regarding pear if pear is so important it would be nice if pear was at
least 5.0 code. All of it.
This statement is ridiculous and disappoints me, Marcus.
Regards,
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz
On Fri, 25 Nov 2005 20:48:28 +0100
helly@php.net (Marcus Boerger) wrote:
And it doesn't help to shout or whine along.
I do not consider pointing out the total lack of respect some
people suffer as whining or shouting. I do not consider to warn about a
critical problem (for many people at least) as shouting.
Take the lessen and test next time. All of us. All th ecode they want
to use.
As far as I can see now, "we" do not learn from our mistakes.
And as Andi stated. PHP 5.1 is a lot of very good work. Anybody who
participated in its making should be proud.
It is a real good work, only sad that one person does not consider the
consequences of his actions and lies.
p.s.: Regarding pear if pear is so important it would be nice if pear
was at least 5.0 code. All of it.
You are totally missing my point, the main problem here and the
consequences. Blaming non prefixed names, people having not tested the
last 2 RC or anybody else but this person is wrong, period.
--Pierre
Marcus Boerger wrote:
Hello Guys,
simply because the crew that actually develops php and tests it a lot
before a release obviously doesn't use PEAR. And given the fact that pear
was dropped from the main releases because it didn't fit into it
functionality and compatibility wise anyway i see no reason to change this
dropped from the main releases? I need a clarification on this one.
Thanks,
Greg
Hello Greg,
we previously shipped a lot of pear classes and now we only ship the
installer. Back when we had the pear classes in the main distro i used
to test them even though i didn't use any of them. Right now the only
stuff i test is stuff i really use and that is a single pear class and
that i haven't been updating for 2 years.
marcus
Saturday, November 26, 2005, 7:37:08 AM, you wrote:
Marcus Boerger wrote:
Hello Guys,
simply because the crew that actually develops php and tests it a lot
before a release obviously doesn't use PEAR. And given the fact that pear
was dropped from the main releases because it didn't fit into it
functionality and compatibility wise anyway i see no reason to change this
dropped from the main releases? I need a clarification on this one.
Thanks,
Greg
Best regards,
Marcus
Marcus Boerger wrote:
Hello Helgi,
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.
I absolutely agree with these points. It is also worth noting that the
coding standards of prefixing classes were introduced long after
packages like "Date" existed. We have a case of a userbase and a
shifting foundation that is PHP.
Perhaps the best future of PEAR is to design with those shifting sands
in mind as more of a primary design concern. There's plenty of time
before PHP 6, so we can get this taken care of by then, I think.
These are just preliminary thoughts, but it is imperative that all PEAR
classes be tested, and by inference testable, with PHP releases.
Anything that comes from .php.net should work with PHP, or at least be
given a chance to fix the problem before the release. This means a
tighter integration of PEAR developers and PHP internals, by no means an
easy task, as is shown by Pierre's tribulations over Date.
At the least, it would make sense to provide some kind of PEAR-related
RC cycle for PHP releases. I will see if I can shake up some ideas on
how to get PEAR more involved (at least better involved) in the PHP
release process over on pear-dev and report back.
Greg
Hello Greg,
Saturday, November 26, 2005, 1:20:36 AM, you wrote:
Marcus Boerger wrote:
Hello Helgi,
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.
I absolutely agree with these points. It is also worth noting that the
coding standards of prefixing classes were introduced long after
packages like "Date" existed. We have a case of a userbase and a
shifting foundation that is PHP.
Perhaps the best future of PEAR is to design with those shifting sands
in mind as more of a primary design concern. There's plenty of time
before PHP 6, so we can get this taken care of by then, I think.
These are just preliminary thoughts, but it is imperative that all PEAR
classes be tested, and by inference testable, with PHP releases.
Anything that comes from .php.net should work with PHP, or at least be
given a chance to fix the problem before the release. This means a
tighter integration of PEAR developers and PHP internals, by no means an
easy task, as is shown by Pierre's tribulations over Date.
At the least, it would make sense to provide some kind of PEAR-related
RC cycle for PHP releases. I will see if I can shake up some ideas on
how to get PEAR more involved (at least better involved) in the PHP
release process over on pear-dev and report back.
Very well said. I hope you can do something on the PEAR front. For the PHP
front i am already working on some automatic testing. Once that's done we
will look for a way to bring in PEAR tests into it as well.
Best regards,
Marcus
Rasmus Lerdorf wrote:
Pierre, I agree with you that it was a bad idea to turn on the stub date
class in the final release candidate giving people less than a week to
notice that we now conflict with a common pear class. We get all the
breakage and none of the benefits and nobody had any time to prepare the
pear side of the house for this. It also sucks that not a single pear
person tested the final RC and brought this up in the past week. There
is plenty of blame to go around here.
Rasmus - the main problem here is that there is TOO much going on with
PHP and while everything can be justified it is just adding to the NON
take up of PHP5!
PHP5 needs a STABLE code base so we can convince people that PHP4 is
dead and stop adding functionality to that. At the same time many of us
need PHP6 NOW just for the Unicode stuff. There are too many cooks at
the moment, so many of us who used to download a new version and run it
have switched off. I do not plan to run 5.1 in production because I've
only JUST got 5.0.5 stable and I don't want yet another round of
tweaking hidden bugs ( I use my OWN date/time stuff ! ). I'll wait for
PHP6 now before I switch again since PHP5.0.5 is stable for me !!! and
if users want to use my code with the latest PHP4.4 they can fix the
pigging bugs themselves :)
The one thing that needs to happen is a roadmap that actually plans a
single stable code base that we can all use in production and that does
not tread on everybody elses toes with every release. Has NOBODY
learnt that "It was wrong so we fixed it" is only acceptable if there is
a clean path to advising users how to fix things and not simply hide all
the now broken code behind messages?
While plowing forward in an attempt to add lots of extra wiz bang
features Microsoft like may seem essential, we end up with the same
problems - how many people still use W95 ;)
Rather than work on a PHP4 fork, how about a means of converting PHP4
code so it will work on PHP5, and when something needs fixing in PHP5
check and warn rather than break? If you want more of us to test RC's
you need to restore confidence that it's worth the effort :(
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
Lester Caine wrote:
Rather than work on a PHP4 fork, how about a means of converting PHP4
code so it will work on PHP5, and when something needs fixing in PHP5
check and warn rather than break? If you want more of us to test RC's
you need to restore confidence that it's worth the effort :(
This particular issue has nothing to do with PHP 4. As far as everyone
agreeing on a single release/code base. I don't see that happening. We
are all on different timelines here with different requirements. I
skipped PHP 5.0.x completely, for example, and will move everything to
PHP 5.1 because it fit my schedule best and the performance and features
in 5.1 meet my requirements. You decided on PHP 5.0.5.
And we are not a software company building software for our customers
here. We are all customers who happen to have similar requirements and
collaborate, for better or worse, on a unified approach to meeting these
requirements. As these requirements diverge with the larger
customer-base it becomes harder and harder to coordinate, but I don't
see how we can massage the situation to get everyone on the same page
without alienating pretty much everyone. We have to find the balance
between meeting the stability requirements for the customers who are
perfectly happy with the featureset in PHP 4.x and don't want anything
to change, the folks who want the simpler XML handling, SOAP and
stronger OO in PHP 5 and then the group that need full Unicode support
yesterday.
We have a proposed roadmap for PHP 6 in terms of features and changes.
There are no dates on that roadmap because frankly that is impossible to
do in a project like this.
-Rasmus
Rasmus Lerdorf wrote:
We have to find the balance
between meeting the stability requirements for the customers who are
perfectly happy with the featureset in PHP 4.x and don't want anything
to change, the folks who want the simpler XML handling, SOAP and
stronger OO in PHP 5 and then the group that need full Unicode support
yesterday.
I'd be happy with that if the same people who claim to be happy with
PHP4 did not complain when code I've produced for PHP5 and provide open
sourced does not run for them - even given that most of the Firebird
stuff was never back ported to PHP4 anyway! (Which is why I've never
used PHP4 in production either)
We have a proposed roadmap for PHP 6 in terms of features and changes.
There are no dates on that roadmap because frankly that is impossible to
do in a project like this.
That is one I am following with interest, and I have a large archive of
unicode data ready to apply to the results :) But PLEASE can we have
windows builds to play with from time to time ;) Some of us still do not
have the tools to build one ourselves :(
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
That is one I am following with interest, and I have a large archive of
unicode data ready to apply to the results :) But PLEASE can we have
windows builds to play with from time to time ;) Some of us still do not
have the tools to build one ourselves :(
It seems microsoft gives you these tools for free nowadays:
http://msdn.microsoft.com/visualc/vctoolkit2003/
--
Met vriendelijke groeten,
Tim Van Wassenhove <http://timvw.madoka.be
Rasmus Lerdorf schrieb:
Pierre, I agree with you that it was a bad idea to turn on the stub date
class in the final release candidate giving people less than a week to
notice that we now conflict with a common pear class. We get all the
breakage and none of the benefits and nobody had any time to prepare the
pear side of the house for this. It also sucks that not a single pear
person tested the final RC and brought this up in the past week. There
is plenty of blame to go around here.
Less than a week? OK; I'm just a private programmer and not from the
PEAR team. I am not compiling my own PHP, I use Debian with the ~dexter
builds. I got my RC6 YESTERDAY! And it breaks my code. I would have
commented on this but just minutes later I learned that 5.1.0 had been
released.
Five minutes notice, now that's tight schedule.
OLLi