Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there) [RSS Feed]

#1 Nov. 25, 2005 02:45:41

P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


On Thu, 24 Nov 2005 16:15:04 -0800
(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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 Nov. 25, 2005 02:53:01

Ilia A.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


Pierre wrote:
> On Thu, 24 Nov 2005 16:15:04 -0800
> (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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Nov. 25, 2005 08:19:21

Marcus B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


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:

> On Fri, 25 Nov 2005 15:16:43 +0800, Alan Knowles 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Nov. 25, 2005 08:28:30

Jessie H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


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

Friday, November 25, 2005, 8:40:47 AM, you wrote:On Fri, 25 Nov 2005 15:16:43 +0800, Alan Knowles 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--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Nov. 25, 2005 08:42:30

Lukas S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


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 nameswhen we add functionality currently missing in PHP. Just as well itmakes 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 maybe because the PEAR API sucks. It may also be caused by the fact thatusually our implementation will probably be written for a previous PHPversion.In a perfect world we would define an API, implement it in PEAR as atestbed for interest and if we find its popular and there aresignificant performance improvements to expect from an implementation inC we take that API and implement it in C.However I do not see this happening ever. So I do not see a point inPEAR packages claiming away nice and clear names from php core. Weshould either cooperate on the API level or just have php core superseedPEAR stuff.PEAR then goes and fixes whatever breakage occurs. What however would benice is some advance notice. And where is the entry in the upgradingguide? Oh and for the record if there is a PEAR class by the name ofDate 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 thanPEAR also have a Date class. Maybe we need to teach our users (includingPEAR) that they should simply stick to prefixing everything with 3-4letter 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 Nov. 25, 2005 09:11:53

Marcus B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Nov. 25, 2005 09:14:24

Lukas S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


Marcus Boerger wrote:So in conclusion its needlessly messy. I am sure other projects thanPEAR also have a Date class. Maybe we need to teach our users (includingPEAR) that they should simply stick to prefixing everything with 3-4letter 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 thepoint where you start of from scratch, php5 only etc .. but this is atopic for the pear mailinglists)regards,
Lukas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Nov. 25, 2005 10:02:36

Sebastian K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Nov. 25, 2005 10:34:11

Christian S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


Lukas Smith wrote:Marcus Boerger wrote:That conclusion means stay with date in ext/date and have pear learn thelesson by making the same mistake in core. Once again the onlysolution isnamespacing.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: Everysingle application out there defining a Date class has to be changed ifthe core adds a class with the same name.Is this common? One of our running gags here is that every project endsup adding its own set of date formating/conversion functions/classes atsome point. So unless people are prefixing all local classes there is arather good chance of having a class named Date in quite some projects.Section of CODING_STANDARDS Naming Conventions states that "Theclass name should be prefixed with the name of the 'parent set'" but atthe same time lists "Curl" as good. Now my question is whether theprefixing should be enforced (at least when a common name like Date isused)?Or
a) am I missing somethingb) is it the core developers' opinion that core classes have the rightof way?- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#10 Nov. 25, 2005 10:47:29

Matthias P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)


> Or
> a) am I missing something
> b) is it the core developers' opinion that core classes have
> the right of way?

<kidding>
If things behave like that at least there should be a list of "reserved
class names" just like with other keywords. And of course that list must
not be changed as it is considered practical.
</kidding>

I don't think PEAR has done anything wrong here; it was never disallowed
to have a class named Date. And it's not only a PEAR problem but affects
pretty much everyone out there with more than a few hundred lines of OO
code. If it was a failure of QA, clearly one of the "language core" QA
itself.

Maybe namespaces are a solution, but until there is a good solution for
the basic problem, stop adding classes to the core that way. Often it's
hard enough to find short yet precise class names; and there is also a
set of commonly used or agreed-on class names (just think of the common
patterns). In no case anything done in the core must inflict with or
otherwise touch that set - or forget about that "enterprise ready" stuff
altogether.

-mp.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there) [RSS Feed]

Board footer

Moderator control

Enjoy the 27th of April
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support