Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » E_ALL changes in 5.2/6.0 »

E_ALL changes in 5.2/6.0

php.internals

Marcus Börger

20 years ago
Hello internals, by accident i added both E_STRICT and E_RECOVERABLE_ERROR to E_ALL while MFHing new features as discussed beforehand while decision was only to MFH E_RECOVERABLE_ERROR and not to put E_STRICT into E_ALL. See: http://oss.backendmedia.com/PhP52 Now the idea of E_STRICT is that core developers can inform users about changes in upcoming versions of php as early as possible. So developers should have E_ALL including E_STRICT enabled during development so that they are able to develop clean applications that most likely will work in the next version. On the production machines you would still either not use E_ALL or log only and don't show the errors in the application. That said i am about to not remove E_STRICT from E_ALL and MFH the php 6.0 to item just now. See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry)) Since this is for the benefit of the users to prevent issues with changes in behavior from my opinion it is best to do this behavior change as early as possible, which is in my opinion 5.2 anyway. That said i'll let it in and if there is no valid argument against, i will put it into the NEWS file and the newly started README.UPDATE_5_2. Best regards, Marcus

Pierre Joye

20 years ago
On Sun, 14 May 2006 20:59:03 +0200 helly@php.net (Marcus Boerger) wrote:
> Now the idea of E_STRICT is that core developers can inform users > about changes in upcoming versions of php as early as possible. So > developers should have E_ALL including E_STRICT enabled during > development so that they are able to develop clean applications that > most likely will work in the next version. On the production machines > you would still either not use E_ALL or log only and don't show the > errors in the application.
Sorry but I do not buy these arguments. As it is clear than nobody should have display_errors On on a production servers, that does not mean we can do that. I see it as a breakage.
> That said i am about to not remove E_STRICT from E_ALL and MFH the php > 6.0 to item just now. > See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE > (dmitry))
It was planed for 6.0 for a good reason. 5.1.x is dead, but we are fixing many issues (including security problems) in 5.2.x, many people will not update because of the "breakages". I see that as a strategic mistake.
> Since this is for the benefit of the users to prevent issues with > changes in behavior from my opinion it is best to do this behavior > change as early as possible, which is in my opinion 5.2 anyway.
On the other side it is for the benefit of our users to prevent breakages and useless annoyances.
> That said i'll let it in and if there is no valid argument against, i > will put it into the NEWS file and the newly started > README.UPDATE_5_2.
I already asked you (without answer) to tell me which cases you consider critical and thus should be moved to E_ALL. Which are they? -- Pierre

Marcus Börger

20 years ago
Hello Pierre, Monday, May 15, 2006, 2:39:02 AM, you wrote:
> On Sun, 14 May 2006 20:59:03 +0200 > helly@php.net (Marcus Boerger) wrote:
>> That said i am about to not remove E_STRICT from E_ALL and MFH the php >> 6.0 to item just now. >> See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE >> (dmitry))
> It was planed for 6.0 for a good reason. 5.1.x is dead, but we are > fixing many issues (including security problems) in 5.2.x, many people > will not update because of the "breakages". I see that as a strategic > mistake.
You are speaking of PHP 4 people here.
>> Since this is for the benefit of the users to prevent issues with >> changes in behavior from my opinion it is best to do this behavior >> change as early as possible, which is in my opinion 5.2 anyway.
> On the other side it is for the benefit of our users to prevent > breakages and useless annoyances.
If you don't like E_STRICT you can simply set E_ALL without it in your ini, stay with a version of your likes as Steph suggested and live happily ever after.
>> That said i'll let it in and if there is no valid argument against, i >> will put it into the NEWS file and the newly started >> README.UPDATE_5_2.
> I already asked you (without answer) to tell me which cases you > consider critical and thus should be moved to E_ALL. Which are they?
Critical? I said that any changes that have a behavior impact should be documented. I hope i didn't miss anything besides E_STRICT which faith hasn't been decided yet. But guess what, you're more then welcome to update and write additions to the update file instead of only complaining. Best regards, Marcus

Steph

20 years ago
Marcus, FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL switched on anywhere but a dev box? - and when there is the option to switch on E_ALL without E_STRICT, it makes it much easier to miss useful information about the direction PHP is going in. Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't live here any more' one (which was removed two months ago in PHP_5_1 branch) and the 'only variables can be passed by reference' one (which is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty rare to even _see_ an E_STRICT when you're migrating PHP 4 code to PHP 5 - although it isn't necessarily rare when you're finding your way around 5.x with new code. But that's OK, because writing new code following a language upgrade really should be a learning process - if it isn't, you might as well just stay with the old version for as long as you can - and if you're learning, having these mild slaps on the wrist is genuinely useful. Migrating old code, on the other hand, shouldn't be a learning process unless there's a real need for that. Given that the vars deprecation notice is gone, I don't think there's anything _unnecessarily_ blocking the upgrade path any more in that sense. Correct me if I'm wrong... - Steph PS Pierre I should've replied to your post instead really, but my mail client doesn't handle newsgroup posters too well :\

Greg Beaver

20 years ago
Steph Fox wrote:
> Marcus, > > FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL > switched on anywhere but a dev box? - and when there is the option to > switch on E_ALL without E_STRICT, it makes it much easier to miss > useful information about the direction PHP is going in. > > Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't > live here any more' one (which was removed two months ago in PHP_5_1 > branch) and the 'only variables can be passed by reference' one (which > is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty rare
Side note: calling functions statically that do not have a static modifier causes E_STRICT. Hello PEAR::isError() This is of course going to be a fatal in PHP 6, but it is now the most common E_STRICT I see in PHP4-based code. I agree that it is appropriate to change something like this in a 5.X.0, but it will be a headache for anyone running legacy apps (not just PEAR). Until someone writes some killer apps in PHP5 to replace phpBB and company, changes of this nature will simply prevent moving to PHP5 but that's another story and not the concern of internals (I agree with this strongly). If you all are willing to deal with the fallout (think PHP 4.4) then that's that. Greg

Ilia A.

20 years ago
My opinion is that if we intend to make something stop working (give fatal error) in future releases we need to provide some form of notice be it E_STRICT or E_NOTICE to our users now, so they can anticipate the change. As far as inclusion of E_STRICT into E_ALL, I think this is a good idea, but is probably premature for the 5.2 release. On 15-May-06, at 6:51 AM, Greg Beaver wrote:
> Steph Fox wrote: >> Marcus, >> >> FWIW I'm with you (unusually) over E_STRICT. Why would anyone have >> E_ALL >> switched on anywhere but a dev box? - and when there is the option to >> switch on E_ALL without E_STRICT, it makes it much easier to miss >> useful information about the direction PHP is going in. >> >> Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't >> live here any more' one (which was removed two months ago in PHP_5_1 >> branch) and the 'only variables can be passed by reference' one >> (which >> is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty >> rare > > Side note: calling functions statically that do not have a static > modifier causes E_STRICT. Hello PEAR::isError() > > This is of course going to be a fatal in PHP 6, but it is now the most > common E_STRICT I see in PHP4-based code. > > I agree that it is appropriate to change something like this in a > 5.X.0, > but it will be a headache for anyone running legacy apps (not just > PEAR). Until someone writes some killer apps in PHP5 to replace phpBB > and company, changes of this nature will simply prevent moving to PHP5 > but that's another story and not the concern of internals (I agree > with > this strongly). If you all are willing to deal with the fallout > (think > PHP 4.4) then that's that. > > Greg > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Ilia Alshanetsky Advanced Internet Designs Inc. ilia@prohost.org

Derick Rethans

20 years ago
On Mon, 15 May 2006, Ilia Alshanetsky wrote:
> My opinion is that if we intend to make something stop working (give fatal > error) in future releases we need to provide some form of notice be it > E_STRICT or E_NOTICE to our users now, so they can anticipate the change. As > far as inclusion of E_STRICT into E_ALL, I think this is a good idea, but is > probably premature for the 5.2 release.
Then when do you suggest we add it (before 6.0)? regards, Derick

Ilia A.

20 years ago
I suggest that we add E_STRICT now, but not include E_STRICT into E_ALL, so people who are not using E_STRICT error reporting level don't have their applications start spewing strict messages. We cannot force people to change their code, all we can reasonably do is provide notification mechanism, for those who do. On 15-May-06, at 9:16 AM, Derick Rethans wrote:
> On Mon, 15 May 2006, Ilia Alshanetsky wrote: > >> My opinion is that if we intend to make something stop working >> (give fatal >> error) in future releases we need to provide some form of notice >> be it >> E_STRICT or E_NOTICE to our users now, so they can anticipate the >> change. As >> far as inclusion of E_STRICT into E_ALL, I think this is a good >> idea, but is >> probably premature for the 5.2 release. > > Then when do you suggest we add it (before 6.0)? > > regards, > Derick >
Ilia Alshanetsky Advanced Internet Designs Inc. ilia@prohost.org

Marcus Börger

20 years ago
Hello Ilia, Monday, May 15, 2006, 3:23:18 PM, you wrote:
> I suggest that we add E_STRICT now, but not include E_STRICT into > E_ALL,
We added E_STRICT in what 5.0 or or 5.1? Guess i checked it: marcus@zaphod /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h|grep E_STRICT Annotations for Zend/zend_errors.h *************** 1.15 (andi 18-Nov-03): #define E_STRICT (1<<11L) 1.22 (dmitry 16-Mar-06): #define E_ALL (E_ERROR | E_WARNING | E_PARSE | E_N marcus@zaphod /usr/src/php-cvs $ cvs log Zend/zend_errors.h|grep php_5_0_0b php_5_0_0b4: 1.17 php_5_0_0b4RC1: 1.17 php_5_0_0b3: 1.16 php_5_0_0b3RC2: 1.16 php_5_0_0b3RC1: 1.16 php_5_0_0b2: 1.14 php_5_0_0b2RC1: 1.14 php_5_0_0b1: 1.14 marcus@zaphod /usr/src/php-cvs $
> so people who are not using E_STRICT error reporting level > don't have their applications start spewing strict messages. > We cannot force people to change their code, all we can reasonably do > is provide notification mechanism, for those who do.
Yes and that is E_STRICT. And if we continue the way we do now we will have not only unicode problems when people upgrade to 6...
> On 15-May-06, at 9:16 AM, Derick Rethans wrote:
>> On Mon, 15 May 2006, Ilia Alshanetsky wrote: >> >>> My opinion is that if we intend to make something stop working >>> (give fatal >>> error) in future releases we need to provide some form of notice >>> be it >>> E_STRICT or E_NOTICE to our users now, so they can anticipate the >>> change. As >>> far as inclusion of E_STRICT into E_ALL, I think this is a good >>> idea, but is >>> probably premature for the 5.2 release. >> >> Then when do you suggest we add it (before 6.0)? >> >> regards, >> Derick >>
> Ilia Alshanetsky > Advanced Internet Designs Inc. > ilia@prohost.org
Best regards, Marcus

Ilia A.

20 years ago
Erhm... I meant, add E_STRICT warning message to the code to the deprecated oo code. On 15-May-06, at 2:35 PM, Marcus Boerger wrote:
> Hello Ilia, > > Monday, May 15, 2006, 3:23:18 PM, you wrote: > >> I suggest that we add E_STRICT now, but not include E_STRICT into >> E_ALL, > > We added E_STRICT in what 5.0 or or 5.1? Guess i checked it: > marcus@zaphod /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h| > grep E_STRICT > > Annotations for Zend/zend_errors.h > *************** > 1.15 (andi 18-Nov-03): #define > E_STRICT (1<<11L) > 1.22 (dmitry 16-Mar-06): #define E_ALL (E_ERROR | > E_WARNING | E_PARSE | E_N > marcus@zaphod /usr/src/php-cvs $ cvs log Zend/zend_errors.h|grep > php_5_0_0b > php_5_0_0b4: 1.17 > php_5_0_0b4RC1: 1.17 > php_5_0_0b3: 1.16 > php_5_0_0b3RC2: 1.16 > php_5_0_0b3RC1: 1.16 > php_5_0_0b2: 1.14 > php_5_0_0b2RC1: 1.14 > php_5_0_0b1: 1.14 > marcus@zaphod /usr/src/php-cvs $ > >> so people who are not using E_STRICT error reporting level >> don't have their applications start spewing strict messages. >> We cannot force people to change their code, all we can reasonably do >> is provide notification mechanism, for those who do. > > Yes and that is E_STRICT. And if we continue the way we do now we > will have > not only unicode problems when people upgrade to 6... > >> On 15-May-06, at 9:16 AM, Derick Rethans wrote: > >>> On Mon, 15 May 2006, Ilia Alshanetsky wrote: >>> >>>> My opinion is that if we intend to make something stop working >>>> (give fatal >>>> error) in future releases we need to provide some form of notice >>>> be it >>>> E_STRICT or E_NOTICE to our users now, so they can anticipate the >>>> change. As >>>> far as inclusion of E_STRICT into E_ALL, I think this is a good >>>> idea, but is >>>> probably premature for the 5.2 release. >>> >>> Then when do you suggest we add it (before 6.0)? >>> >>> regards, >>> Derick >>> > >> Ilia Alshanetsky >> Advanced Internet Designs Inc. >> ilia@prohost.org > > > > > > > Best regards, > Marcus > >
Ilia Alshanetsky Advanced Internet Designs Inc. ilia@prohost.org

Todd Ruth

20 years ago
On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote: ...
> Side note: calling functions statically that do not have a static > modifier causes E_STRICT. Hello PEAR::isError() > > This is of course going to be a fatal in PHP 6, but it is now the most > common E_STRICT I see in PHP4-based code.
Yikes! Please say it isn't so! There are significant portions of our app that rely on php's ability to make "semi-static" calls. It would never be worth the cost of upgrading to php6 if that were the case. It's not the best style, but we have scores of classes that have several members in common and need common functionality for those members. In php5 and earlier, you can add helper classes and call helper functions with the "::" syntax. The helper can access all of the members of the main class as if it were its own. The "right" thing to do would be to step back in the design and move the members to other classes, etc., but as practical matter, sometimes that's just not worth the effort to make such drastic changes to code that's developed by accretion. Another use is that we have core data that most classes keep in an "$application" member variable. It's sort of like a global, but to allow for a couple instances of a class to work on different app data, we've taken the member route instead of the global route. php is a nice language for this in that we don't have to pass $application to every static function we call. The static function has access to $this->application, because everyone who calls the static function has the application member. Please don't fatal error this code in php 6! Thanks for listening, Todd

Marcus Börger

20 years ago
Hello Todd, Monday, May 15, 2006, 6:03:14 PM, you wrote:
> On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote: > ... >> Side note: calling functions statically that do not have a static >> modifier causes E_STRICT. Hello PEAR::isError() >> >> This is of course going to be a fatal in PHP 6, but it is now the most >> common E_STRICT I see in PHP4-based code.
> Yikes! Please say it isn't so! There are significant portions of > our app that rely on php's ability to make "semi-static" calls. It > would never be worth the cost of upgrading to php6 if that were the > case.
> It's not the best style, but we have scores of classes that > have several members in common and need common functionality > for those members. In php5 and earlier, you can add helper > classes and call helper functions with the "::" syntax. The > helper can access all of the members of the main class as if > it were its own. The "right" thing to do would be to step > back in the design and move the members to other classes, > etc., but as practical matter, sometimes that's just not > worth the effort to make such drastic changes to code that's > developed by accretion.
> Another use is that we have core data that most classes keep > in an "$application" member variable. It's sort of like a > global, but to allow for a couple instances of a class to > work on different app data, we've taken the member route > instead of the global route. php is a nice language for this > in that we don't have to pass $application to every static > function we call. The static function has access to > $this->application, because everyone who calls the static > function has the application member.
> Please don't fatal error this code in php 6!
> Thanks for listening, > Todd
Ever heared of the concept named root class?

Todd Ruth

20 years ago
On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
> Monday, May 15, 2006, 6:03:14 PM, you wrote: > > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote: > > ... > >> Side note: calling functions statically that do not have a static > >> modifier causes E_STRICT. Hello PEAR::isError() > >> > >> This is of course going to be a fatal in PHP 6, but it is now the most > >> common E_STRICT I see in PHP4-based code. > > > Yikes! Please say it isn't so! There are significant portions of > > our app that rely on php's ability to make "semi-static" calls. It > > would never be worth the cost of upgrading to php6 if that were the > > case. > > > It's not the best style, but we have scores of classes that > > have several members in common and need common functionality > > for those members. In php5 and earlier, you can add helper > > classes and call helper functions with the "::" syntax. The > > helper can access all of the members of the main class as if > > it were its own. The "right" thing to do would be to step > > back in the design and move the members to other classes, > > etc., but as practical matter, sometimes that's just not > > worth the effort to make such drastic changes to code that's > > developed by accretion. > > > Another use is that we have core data that most classes keep > > in an "$application" member variable. It's sort of like a > > global, but to allow for a couple instances of a class to > > work on different app data, we've taken the member route > > instead of the global route. php is a nice language for this > > in that we don't have to pass $application to every static > > function we call. The static function has access to > > $this->application, because everyone who calls the static > > function has the application member. > > > Please don't fatal error this code in php 6! > > > Thanks for listening, > > Todd > > > Ever heared of the concept named root class?
Yes, but it isn't a substitute for the semi-statics. Including comments, etc., our php files total about 130,000 lines. If it were a small, simple app, I could shove the helpers into a root class and it wouldn't be much worse than the search & replaces needed to get to php5. The arguments against our code would be the standard arguments against multiple inheritance. (The semi- statics provide something very similar to multiple inheritance.) Like many large apps that have evolved over many years, this isn't because it was designed that way; it is because much of it wasn't designed at all. It just grew. The good news is that it ran great on php4 and it hasn't been too much trouble to get rid of the issues with getting it to run great on php5. I'm hoping php6 doesn't give up so much backward compatibility that we'll never be able to use it. BTW, I've tried to come up with a short example to give a flavor of what I want to preserve, but anything short is too easy to refactor and say "it should have been done differently". It's true that many aspects of our app should have been done differently, but its difficult to change something so large. I don't see benefits of making semi-static fatal that make it worth keeping those of us with large apps that depend on semi- static from upgrading to php6. Is there a significant performance enhancement in the engine that depends on eliminating semi-static or somesuch? - Todd

Marcus Börger

20 years ago
Hello Todd, Monday, May 15, 2006, 9:32:21 PM, you wrote:
> On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote: >> Monday, May 15, 2006, 6:03:14 PM, you wrote: >> > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote: >> > ... >> >> Side note: calling functions statically that do not have a static >> >> modifier causes E_STRICT. Hello PEAR::isError() >> >> >> >> This is of course going to be a fatal in PHP 6, but it is now the most >> >> common E_STRICT I see in PHP4-based code. >> >> > Yikes! Please say it isn't so! There are significant portions of >> > our app that rely on php's ability to make "semi-static" calls. It >> > would never be worth the cost of upgrading to php6 if that were the >> > case. >> >> > It's not the best style, but we have scores of classes that >> > have several members in common and need common functionality >> > for those members. In php5 and earlier, you can add helper >> > classes and call helper functions with the "::" syntax. The >> > helper can access all of the members of the main class as if >> > it were its own. The "right" thing to do would be to step >> > back in the design and move the members to other classes, >> > etc., but as practical matter, sometimes that's just not >> > worth the effort to make such drastic changes to code that's >> > developed by accretion. >> >> > Another use is that we have core data that most classes keep >> > in an "$application" member variable. It's sort of like a >> > global, but to allow for a couple instances of a class to >> > work on different app data, we've taken the member route >> > instead of the global route. php is a nice language for this >> > in that we don't have to pass $application to every static >> > function we call. The static function has access to >> > $this->application, because everyone who calls the static >> > function has the application member. >> >> > Please don't fatal error this code in php 6! >> >> > Thanks for listening, >> > Todd >> >> >> Ever heared of the concept named root class?
> Yes, but it isn't a substitute for the semi-statics. Including > comments, etc., our php files total about 130,000 lines. If it > were a small, simple app, I could shove the helpers into a root > class and it wouldn't be much worse than the search & replaces > needed to get to php5. The arguments against our code would be > the standard arguments against multiple inheritance. (The semi- > statics provide something very similar to multiple inheritance.) > Like many large apps that have evolved over many years, this isn't > because it was designed that way; it is because much of it wasn't > designed at all. It just grew. The good news is that it ran > great on php4 and it hasn't been too much trouble to get rid of > the issues with getting it to run great on php5. I'm hoping > php6 doesn't give up so much backward compatibility that we'll > never be able to use it.
PHP also offers interfaces.
> BTW, I've tried to come up with a short example to give a flavor > of what I want to preserve,
No need, i'd just figure misdesign.
> [...] Is there a significant performance > enhancement in the engine that depends on eliminating semi-static > or somesuch?
Security. We might as well enable the crash function in non debug builds. Or just drop 'static' again and go back to the PHP 4 object model. Best regards, Marcus

Richard Lynch

20 years ago
On Mon, May 15, 2006 2:47 pm, Marcus Boerger wrote:
>> [...] Is there a significant performance >> enhancement in the engine that depends on eliminating semi-static >> or somesuch? > > Security. We might as well enable the crash function in non debug > builds. > Or just drop 'static' again and go back to the PHP 4 object model.
I realize I'm the village idiot here, but... How does throwing, say, E_NOTICE or E_OOP_PURIST or something instead of E_FATAL when the programmer does this, turn into a crashing security issue? While encapsulation can be an important component of data-integrity and security in an application's OOP model, I'm just not seeing this as a general security flaw that should halt somebody's program because they prefer a looser encapsulation model in their OOP... Am I being particularly naive or blind here? If so, could you elaborate on how this is a Security concern, and equates with a crash function in non debug builds? Much less regressing to the inherently flawed PHP4 OOP model? If you're sure I'm the only idiot not getting this, feel free to point me to references or reply off-list or just ignore me, as I know you're crazy busy. :-)
-- Like Music? http://l-i-e.com/artists.htm

Edin Kadribasic

20 years ago
Todd Ruth wrote:
> I don't see benefits of making semi-static fatal that make it > worth keeping those of us with large apps that depend on semi- > static from upgrading to php6.
My sentiments exactly. OO purity/strictness do now work well with PHP's main strength -- its dynamicity. Edin

Sebastian Bergmann

20 years ago
Edin Kadribasic wrote:
> OO purity/strictness do now work well with PHP's main strength -- its > dynamicity.
You make it sound like OO and dynamicity were mutually exclusive; they are not. Take a look at Smalltalk or CLOS to see what I mean.
-- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Edin Kadribasic

20 years ago
Sebastian Bergmann wrote:
> Edin Kadribasic wrote: > >>OO purity/strictness do now work well with PHP's main strength -- its >>dynamicity. > > > You make it sound like OO and dynamicity were mutually exclusive; they > are not. Take a look at Smalltalk or CLOS to see what I mean.
I know, but often the arguments used here against dynamicity is that it does not comply with some pure computer science OO paradigm. I do belive PHP can support nice object model and remain dynamic at the same time. Edin

Richard Lynch

20 years ago
On Mon, May 15, 2006 3:17 pm, Sebastian Bergmann wrote:
> Edin Kadribasic wrote: >> OO purity/strictness do now work well with PHP's main strength -- >> its >> dynamicity. > > You make it sound like OO and dynamicity were mutually exclusive; > they > are not. Take a look at Smalltalk or CLOS to see what I mean.
Hey, anytime the OO purists designing the PHP OO language want to abandon Java concepts and head for Lisp or even Smalltalk, I'm all for it :-) :-) :-) PHP's Java-like OOP and dynamicity *are* at odds -- All the requirements of declaring things up front are simply not dynamic in nature. Some folks like it that way ; Some don't. The guys doing all the work like it that way, so there ya go. [shrug] My simple solution to this problem has been to largely ignore PHP OOP :-)
-- Like Music? http://l-i-e.com/artists.htm

Andi Gutmans

20 years ago
I don't see why it has to be a fatal error. If there's an instanceof relationship we can keep $this. If not, we should not pass $this (which I believe we already do in PHP 5), in which case the author would have to pass $this if he wants to change public properties. Andi At 12:49 PM 5/15/2006, Edin Kadribasic wrote:

Todd Ruth

20 years ago
In php5 this works even without an instanceof relationship. (I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.) I know the following test case does not even remotely follow good OO design principles, but it's hard to imagine us going back to the drawing board with our app. Please don't break the following in php6 just to teach me a lesson about OO design. If there's a repository of "someone will complain about a BC break if this changes" tests, please add the following: --TEST-- test that $this survives in a semi-static call --FILE-- <?php class TheParent { public $x = 3; } class UglyUncle { function f() { $this->x = 5; } } class Child extends TheParent { function f() { UglyUncle::f(); } } $c = new Child(); var_dump($c->x); $c->f(); var_dump($c->x); ?> --EXPECT-- int(3) int(5) Thanks, Todd On Mon, 2006-05-15 at 19:41 -0700, Andi Gutmans wrote:
> I don't see why it has to be a fatal error. If there's an instanceof > relationship we can keep $this. If not, we should not pass $this > (which I believe we already do in PHP 5), in which case the author > would have to pass $this if he wants to change public properties. > > Andi > > At 12:49 PM 5/15/2006, Edin Kadribasic wrote: > >Todd Ruth wrote: > >>I don't see benefits of making semi-static fatal that make it > >>worth keeping those of us with large apps that depend on semi- > >>static from upgrading to php6. > > > >My sentiments exactly. OO purity/strictness do now work well with > >PHP's main strength -- its dynamicity. > > > >Edin > > > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php >
-- Todd Ruth <truth@proposaltech.com>

Marcus Börger

20 years ago
Hello Todd, if you need abstract static methods that oo wise make no sense at all but still want them because you know your stuff better than theory then there still is a problem in the engine code we have to maintain. In case we had late static binding already we might have solved all related issues alredy. In the current state the behavior is likely to cause trouble in some cases becuase the engine was not designed to support oo misuse/wron use. It was just an oversight not to have that test on the place - most likely on my side, since i wrote all tests and a lot of the oo rules code. Now that we are finally working with PHP 5 and more than 1% of our users do so as well we find more and more issues. This situation is just like the one where we had to fix reference stuff as we found out that it indeed was causing SEGVs in certain situations. And i want to provide such situations and i want that at nearly all costs because i do not want to have such a situation again. For one reason it took me like a full week of work to help Derick with a tiny piece in debugging and i don't know how much time Derick spend on tracking the issue down and fixing it. In short i rather drop a feature than risking SEGVs. Now decide for your self what is more expensive/more dangerous for you? An unstablel PHP or a tiny feature loss? Btw, right now you can have abstract static methods in interfaces. This was a compromise I introduced when we found out the issue. marcus Wednesday, May 24, 2006, 8:56:06 PM, you wrote:
> In php5 this works even without an instanceof relationship. > (I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.) > I know the following test case does not even remotely follow > good OO design principles, but it's hard to imagine us going > back to the drawing board with our app. Please don't break > the following in php6 just to teach me a lesson about OO design.
> If there's a repository of "someone will complain about a BC > break if this changes" tests, please add the following:
> --TEST-- > test that $this survives in a semi-static call > --FILE-- > <?php > class TheParent { > public $x = 3; > } > class UglyUncle { > function f() { > $this->x = 5; > } > } > class Child extends TheParent { > function f() { > UglyUncle::f(); > } > } > $c = new Child(); > var_dump($c->x); > $c->f(); > var_dump($c->x);
?>>
> --EXPECT-- > int(3) > int(5)
> Thanks, > Todd
> On Mon, 2006-05-15 at 19:41 -0700, Andi Gutmans wrote: >> I don't see why it has to be a fatal error. If there's an instanceof >> relationship we can keep $this. If not, we should not pass $this >> (which I believe we already do in PHP 5), in which case the author >> would have to pass $this if he wants to change public properties. >> >> Andi >> >> At 12:49 PM 5/15/2006, Edin Kadribasic wrote: >> >Todd Ruth wrote: >> >>I don't see benefits of making semi-static fatal that make it >> >>worth keeping those of us with large apps that depend on semi- >> >>static from upgrading to php6. >> > >> >My sentiments exactly. OO purity/strictness do now work well with >> >PHP's main strength -- its dynamicity. >> > >> >Edin >> > >> >-- >> >PHP Internals - PHP Runtime Development Mailing List >> >To unsubscribe, visit: http://www.php.net/unsub.php >>
Best regards, Marcus

Daniel Convissor

20 years ago
On Wed, May 24, 2006 at 11:56:06AM -0700, Todd Ruth wrote:
> <?php > class TheParent { > public $x = 3; > } > class UglyUncle { > function f() { > $this->x = 5; > } > } > class Child extends TheParent { > function f() { > UglyUncle::f(); > } > } > $c = new Child(); > var_dump($c->x); > $c->f(); > var_dump($c->x); > ?> > --EXPECT-- > int(3) > int(5)
"Ugly" is right. As far as I'm concerned, that code should never have worked in the first place. --Dan
-- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Marcus Börger

20 years ago
Hello Todd, code like this is actually exactly what i mean. It is completley broken design, maybe not for you of course. But according to any oo guideline. But that's a different story. The real problem is that this behavior is based on or worked around some behavior in the engine that is sooner or later most likely to cause severs SEGVs. best regards marcus Wednesday, May 24, 2006, 8:56:06 PM, you wrote:
> In php5 this works even without an instanceof relationship. > (I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.) > I know the following test case does not even remotely follow > good OO design principles, but it's hard to imagine us going > back to the drawing board with our app. Please don't break > the following in php6 just to teach me a lesson about OO design.
> If there's a repository of "someone will complain about a BC > break if this changes" tests, please add the following:
> --TEST-- > test that $this survives in a semi-static call > --FILE-- > <?php > class TheParent { > public $x = 3; > } > class UglyUncle { > function f() { > $this->x = 5; > } > } > class Child extends TheParent { > function f() { > UglyUncle::f(); > } > } > $c = new Child(); > var_dump($c->x); > $c->f(); > var_dump($c->x);
?>>
> --EXPECT-- > int(3) > int(5)
> Thanks, > Todd
> On Mon, 2006-05-15 at 19:41 -0700, Andi Gutmans wrote: >> I don't see why it has to be a fatal error. If there's an instanceof >> relationship we can keep $this. If not, we should not pass $this >> (which I believe we already do in PHP 5), in which case the author >> would have to pass $this if he wants to change public properties. >> >> Andi >> >> At 12:49 PM 5/15/2006, Edin Kadribasic wrote: >> >Todd Ruth wrote: >> >>I don't see benefits of making semi-static fatal that make it >> >>worth keeping those of us with large apps that depend on semi- >> >>static from upgrading to php6. >> > >> >My sentiments exactly. OO purity/strictness do now work well with >> >PHP's main strength -- its dynamicity. >> > >> >Edin >> > >> >-- >> >PHP Internals - PHP Runtime Development Mailing List >> >To unsubscribe, visit: http://www.php.net/unsub.php >>
Best regards, Marcus

Marcus Börger

20 years ago
Hello Andi, passing $this to a static function is a different set of problems calling trouble on another front. If you pass $this to a static function you sooner or later pass it as $this and sooner or later you call back into the object scope from that $this. Now the trouble is that suddenly we have two $this. The obejct $this which is a pseudo variable controlled by the engine and which cannot be overwritten and $this in the local symbol table. The one that can be changed and even unset. I am quite sure the engine is not designed to take care for this situations in all places. That said sooner or later the same people complaining now will shout at us: hey you stuff sucks - fix it. marcus Tuesday, May 16, 2006, 4:41:33 AM, you wrote:
> I don't see why it has to be a fatal error. If there's an instanceof > relationship we can keep $this. If not, we should not pass $this > (which I believe we already do in PHP 5), in which case the author > would have to pass $this if he wants to change public properties.
> Andi
> At 12:49 PM 5/15/2006, Edin Kadribasic wrote: >>Todd Ruth wrote: >>>I don't see benefits of making semi-static fatal that make it >>>worth keeping those of us with large apps that depend on semi- >>>static from upgrading to php6. >> >>My sentiments exactly. OO purity/strictness do now work well with >>PHP's main strength -- its dynamicity. >> >>Edin >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php
Best regards, Marcus

Marcus Börger

20 years ago
Hello Greg, Monday, May 15, 2006, 12:51:16 PM, you wrote:
> Steph Fox wrote: >> Marcus, >> >> FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL >> switched on anywhere but a dev box? - and when there is the option to >> switch on E_ALL without E_STRICT, it makes it much easier to miss >> useful information about the direction PHP is going in. >> >> Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't >> live here any more' one (which was removed two months ago in PHP_5_1 >> branch) and the 'only variables can be passed by reference' one (which >> is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty rare
> Side note: calling functions statically that do not have a static > modifier causes E_STRICT. Hello PEAR::isError()
> This is of course going to be a fatal in PHP 6, but it is now the most > common E_STRICT I see in PHP4-based code.
> I agree that it is appropriate to change something like this in a 5.X.0, > but it will be a headache for anyone running legacy apps (not just > PEAR). Until someone writes some killer apps in PHP5 to replace phpBB > and company, changes of this nature will simply prevent moving to PHP5 > but that's another story and not the concern of internals (I agree with > this strongly). If you all are willing to deal with the fallout (think > PHP 4.4) then that's that.
Ones again E_ALL is for development. For example to move PEAR code to PHP 5. It is not for running legacy apps. IF you guys want i'd be ok with adding a new mode say "E_RUN"... Best regards, Marcus

Steph

20 years ago
> Ones again E_ALL is for development. For example to move PEAR code to PHP > 5. > It is not for running legacy apps. IF you guys want i'd be ok with adding > a > new mode say "E_RUN"...
You think that - I think that. After Brian Moon's response I went and checked what the INI files distributed with PHP actually say. ini-dist is set at E_ALL & ~E_NOTICE ini-recommended is set at E_ALL I'd guess that's why Brian reports seeing E_ALL enabled on web hosts; they're advised to use the settings in ini-recommended, after all. (No I don't think we need E_RUN - we just need to rethink this.) - Steph

Brian Moon

20 years ago
Steph Fox wrote:
> ini-dist is set at E_ALL & ~E_NOTICE > ini-recommended is set at E_ALL > > I'd guess that's why Brian reports seeing E_ALL enabled on web hosts; > they're advised to use the settings in ini-recommended, after all.
Perhaps there should be an ini-development and an ini-production.
-- Brian Moon ------------- http://dealnews.com/ Its good to be cheap =)

Marcus Börger

20 years ago
Hello Brian, yeah we should simply rename the two files we have right now to that. I never knew which one to take since their names are not helpful. In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE. While in development we would do E_ALL as in all. Nice idea! best regards marcus Monday, May 15, 2006, 8:49:11 PM, you wrote:
> Steph Fox wrote: >> ini-dist is set at E_ALL & ~E_NOTICE >> ini-recommended is set at E_ALL >> >> I'd guess that's why Brian reports seeing E_ALL enabled on web hosts; >> they're advised to use the settings in ini-recommended, after all.
> Perhaps there should be an ini-development and an ini-production.
> --
> Brian Moon > ------------- > http://dealnews.com/ > Its good to be cheap =)
Best regards, Marcus

Brian Moon

20 years ago
Marcus Boerger wrote:
> Hello Brian, > > yeah we should simply rename the two files we have right now to that. > I never knew which one to take since their names are not helpful. > In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE. > While in development we would do E_ALL as in all.
Of course, in reference to my earlier comments, this will mean that there is a high probablity the casual PHP user that does not run his server will never see the E_STRICT stuff until PHP6. Unfortunately, I can see no way around it.
-- Brian Moon ------------- http://dealnews.com/ Its good to be cheap =)

Richard Lynch

20 years ago
On Mon, May 15, 2006 1:59 pm, Marcus Boerger wrote:
> yeah we should simply rename the two files we have right now to > that. > I never knew which one to take since their names are not helpful. > In production we would set something like E_ALL & ~E_STRICT & > ~E_NOTICE. > While in development we would do E_ALL as in all.
Personally, I've always thought that a smarter setup is to keep E_ALL on all the time, and just turn display_errors off in production, and logging on as an optional in production... But that presumes a quality level in PHP code that's not "out there" yet -- partially because E_ALL wasn't the default for sooooo long, so we had a zillion E_NOTICE messages going un-noticed by the bulk of users. If your production PHP code is generating so many entires in a log file that it's a problem for the log file size, then, really, you've got much bigger problems than the log file size... I can see having the logging off for performance in specific situations, but that would be the people who REALLY know what they're doing anyway. The naive webhost trying to scratch a living out of installing PHP with the default settings and is happy if "it works" is the target audience for the php.ini-recommended -- not the expert than could probably write php.ini from scratch for the settings they care about. YMMV
-- Like Music? http://l-i-e.com/artists.htm

Brian Moon

20 years ago
> If your production PHP code is generating so many entires in a log > file that it's a problem for the log file size, then, really, you've > got much bigger problems than the log file size...
At dealnews, we have been using PHP since PHP/FI. We have written A LOT of code that never expected E_NOTICE to be on. While we strive to write new code in such a way that E_NOTICE would not be a problem (I have gotten used to writing Phorum that way), we do not enable it on our dev machines or production machines due to legacy code. Perhaps when we can make money rewriting all our code from scratch we will look into it. ;)
-- Brian Moon ------------- http://dealnews.com/ Its good to be cheap =)

Andi Gutmans

20 years ago
At 11:49 AM 5/15/2006, Brian Moon wrote:
>Steph Fox wrote: >>ini-dist is set at E_ALL & ~E_NOTICE >>ini-recommended is set at E_ALL >>I'd guess that's why Brian reports seeing E_ALL enabled on web >>hosts; they're advised to use the settings in ini-recommended, after all. > >Perhaps there should be an ini-development and an ini-production.
"recommended" was born after "dist" because we wanted to show how to run PHP correctly (esp. BC breaking INI parameters such as register_globals=off which are recommended). It's a bit different from development vs. production which I agree would be very helpful. Question is how do we do it? Do we abandon the former for the latter, or is there a way to solve all at once? :) Andi

Steph

20 years ago
At 11:49 AM 5/15/2006, Brian Moon wrote:
>>Perhaps there should be an ini-development and an ini-production. > > "recommended" was born after "dist" because we wanted to show how to run > PHP correctly (esp. BC breaking INI parameters such as > register_globals=off which are recommended). It's a bit different from > development vs. production which I agree would be very helpful. Question > is how do we do it? Do we abandon the former for the latter, or is there a > way to solve all at once? :)
Andi, if you go back and actually read those files they claim to be 'default settings' and 'production settings' respectively. I agree the whole idea of 'default settings' should be dropped (in this sense), but I think you'll find most people out there take those directives as 'how PHP should be used'. To me it's a tad worrying - given that context - that the error_reporting recommendations are as they are. Since both files are being, if you like, 'marketed' in the way Brian mentioned, it might be a good time to a) rename them in the way he suggested and b) go through those settings with a fine-toothed comb before doing so. Just an opinion, of course... - Steph

Hannes Magnusson

20 years ago
On 5/14/06, Steph Fox <steph@zend.com> wrote:
> > Ones again E_ALL is for development. For example to move PEAR code to PHP > > 5. > > It is not for running legacy apps. IF you guys want i'd be ok with adding > > a > > new mode say "E_RUN"... > > You think that - I think that. After Brian Moon's response I went and > checked what the INI files distributed with PHP actually say. > > ini-dist is set at E_ALL & ~E_NOTICE > ini-recommended is set at E_ALL
display_errors is however Off in -recommended so it shouldnt matter for those who use it... -Hannes

Jasper Bryant-Greene

20 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Steph Fox wrote:
>> Ones again E_ALL is for development. For example to move PEAR code to >> PHP 5. >> It is not for running legacy apps. IF you guys want i'd be ok with >> adding a >> new mode say "E_RUN"... > > You think that - I think that. After Brian Moon's response I went and > checked what the INI files distributed with PHP actually say. > > ini-dist is set at E_ALL & ~E_NOTICE > ini-recommended is set at E_ALL > > I'd guess that's why Brian reports seeing E_ALL enabled on web hosts; > they're advised to use the settings in ini-recommended, after all.
I see nothing wrong with E_ALL enabled on a production web server - I administer a very busy web server running a large PHP application, and have error_reporting set to E_ALL | E_STRICT. Of course, I do not have display_errors on. Pretty much the only errors I ever get logged are from PEAR, and I have a system to strip these out at the logger level. Jasper -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEaOvYFfAeHhDzT4gRA2QUAJ9ERKmtU7fpGcKmbvzOiZSqnTr1pQCcC3S2 trR/ddzI0bZfmyfmZN0ET1w= =m6k4 -----END PGP SIGNATURE-----

Markus Fischer

20 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Burger wrote:
> Ones again E_ALL is for development.
Is this the statement of all developers or only yours? I have to enable E_ALL on live servers (display_errors to 0), because whatever resource you have at your hand, you just can't make sure that all code paths work properly with all the possible user inputs. It's just not possible. So by logging E_ALL and trying to monitor the log regularly is the only change to spot problems. I would go crazy and have no sleep anymore if I wouldn't do that because I would have no feedback at all how our application performs. You can't just sit and wait for user bug reports. - - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEaNC01nS0RcInK9ARAq/3AKDF4hQto1TeVzE/VRi0j54/Dg9kUwCgwO8q CyR2MtSqWdF+HBMp2Y9cV1Y= =gOMf -----END PGP SIGNATURE-----

Marcus Börger

20 years ago
Hello Markus, Monday, May 15, 2006, 9:04:20 PM, you wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> Marcus Burger wrote: >> Ones again E_ALL is for development.
> Is this the statement of all developers or only yours?
Probably mine, I mean i can only speak for myself here.
> I have to enable E_ALL on live servers (display_errors to 0), because > whatever resource you have at your hand, you just can't make sure that > all code paths work properly with all the possible user inputs. It's > just not possible.
This is very true, yet i don't see a reason to include E_NOTICE and E_STRICT on a production machine. Best regards, Marcus

Richard Lynch

20 years ago
On Mon, May 15, 2006 2:19 pm, Marcus Boerger wrote:
> This is very true, yet i don't see a reason to include E_NOTICE and > E_STRICT > on a production machine.
You've got 100% code coverage with all possible inputs and boundary conditions in your QA process?... Cuz, if not, I really don't see why you'd turn these OFF... Unless, like, you actually send code of to production complete with un-debugged E_NOTICE and E_STRICT messages that would flood your log files... [shrug] At that point, I'd say "logrotate more often" before I'd say turn off E_NOTICE or E_STRICT. Maybe I'm just naive...
-- Like Music? http://l-i-e.com/artists.htm

Brian Moon

20 years ago
> Why would anyone have E_ALL > switched on anywhere but a dev box?
Working with Phorum, I get to peer into lots of different hosting companies setups when helping my users. I have seen many hosts that do have E_ALL enabled and do not log errors because they have no way to provide that log back to their users. Nor would the users have a comprehension of the error log. For the enterprise, I would believe that nearly all production servers shield error output from web pages in one way or another. However, I believe that PHP has its roots in the small web site. If you start making it hard on them to upgrade, you will see hosts that never upgrade their PHP versions.
-- Brian Moon ------------- http://dealnews.com/ Its good to be cheap =)

Steph

20 years ago
>> Why would anyone have E_ALL switched on anywhere but a dev box? > > Working with Phorum, I get to peer into lots of different hosting > companies setups when helping my users. I have seen many hosts that do > have E_ALL enabled and do not log errors because they have no way to > provide that log back to their users. Nor would the users have a > comprehension of the error log. > > For the enterprise, I would believe that nearly all production servers > shield error output from web pages in one way or another. However, I > believe that PHP has its roots in the small web site. If you start making > it hard on them to upgrade, you will see hosts that never upgrade their > PHP versions.
That should be as simple as explicitly offering ;E_ALL & ~E_STRICT in the php.ini (and of course in the upgrade notes too). PHP 5 has been out there for 2 years now, I find it hard to believe that anyone involved - host or user - isn't aware that E_STRICT is on its way. Greg wrote earlier that the biggest issue PEAR has with E_STRICT nowadays comes when non-declared statics are called. Seriously, people writing that kind of code aren't likely to be naive users. I think it's going to be far worse if code that runs cleanly under PHP 4 throws a fatal error in PHP 6 with no mention of it being problematic in between! - Steph

Brian Moon

20 years ago
> I find it hard to believe that anyone > involved - host or user - isn't aware that E_STRICT is on its way.
Honestly, I only heard about it in the last few weeks. And I run an open source project based on PHP. I do PHP for a living. The average web host and/or webmaster does not keep up with the future changes of PHP. You really give web hosts too much credit. They will move from Fedora Core 1 to some distro that has PHP 6 on it directly. They don't update PHP along the way. I am not saying I like this or that it is good. I am saying that this is the way things are. If you want to ignore these users, that is fine. But, I just don't want rose colored glasses making you believe that everyone that uses PHP knows what is happening to PHP.
-- Brian Moon ------------- http://dealnews.com/ Its good to be cheap =)

Marcus Börger

20 years ago
Hello Brian, Monday, May 15, 2006, 6:40:58 PM, you wrote:
>> I find it hard to believe that anyone >> involved - host or user - isn't aware that E_STRICT is on its way.
> Honestly, I only heard about it in the last few weeks. And I run an > open source project based on PHP. I do PHP for a living. The average > web host and/or webmaster does not keep up with the future changes of PHP.
That's exactly the point why we should enable it. Now and not in PHP 9. Best regards, Marcus

Richard Lynch

20 years ago
On Mon, May 15, 2006 9:41 am, Brian Moon wrote:
>> Why would anyone have E_ALL >> switched on anywhere but a dev box? > > Working with Phorum, I get to peer into lots of different hosting > companies setups when helping my users. I have seen many hosts that > do > have E_ALL enabled and do not log errors because they have no way to > provide that log back to their users. Nor would the users have a > comprehension of the error log. > > For the enterprise, I would believe that nearly all production servers > shield error output from web pages in one way or another. However, I > believe that PHP has its roots in the small web site. If you start > making it hard on them to upgrade, you will see hosts that never > upgrade > their PHP versions.
A quick Google for common PHP error messages will almost for sure find you a zillion sites with E_ALL in production servers. I'm not saying it's the Right Way to do things -- I'm saying it's the way a LOT of hosts are set up by default, and their users don't know how to change it, or don't consider the security implications serious enough.
-- Like Music? http://l-i-e.com/artists.htm

Brian Moon

20 years ago
> A quick Google for common PHP error messages will almost for sure find > you a zillion sites with E_ALL in production servers.
2.1 million in fact. http://www.google.com/search?q=notice+undefined+php
-- Brian Moon ------------- http://dealnews.com/ Its good to be cheap =)

Sebastian Mendel

20 years ago
Steph Fox schrieb:
> Marcus, > > FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL > switched on anywhere but a dev box?
at least i, as no one on this mailing list is interested in me, but i have it on and it is logged only and not displayed. some bugs are really hard to find, cause it is not always possible to test every aspect of an application - it is a dream to think you can get you application absolutely error free and failsafe - and how would you recognize errors your customers get if you not enable error reporting? you could say E_ERROR or E_WARNING would be enough but some logical errors throw only E_NOTICE if they throw any error at all ...
-- Sebastian

Derick Rethans

20 years ago
On Sun, 14 May 2006, Marcus Boerger wrote:
> That said i am about to not remove E_STRICT from E_ALL and MFH the php > 6.0 to item just now. > See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry)) > > Since this is for the benefit of the users to prevent issues with > changes in behavior from my opinion it is best to do this behavior > change as early as possible, which is in my opinion 5.2 anyway. > > That said i'll let it in and if there is no valid argument against, i > will put it into the NEWS file and the newly started README.UPDATE_5_2.
Yup, I agree on this. regards, Derick

Lukas Smith

20 years ago
Derick Rethans wrote:
> On Sun, 14 May 2006, Marcus Boerger wrote: > >> That said i am about to not remove E_STRICT from E_ALL and MFH the php >> 6.0 to item just now. >> See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry)) >> >> Since this is for the benefit of the users to prevent issues with >> changes in behavior from my opinion it is best to do this behavior >> change as early as possible, which is in my opinion 5.2 anyway. >> >> That said i'll let it in and if there is no valid argument against, i >> will put it into the NEWS file and the newly started README.UPDATE_5_2. > > Yup, I agree on this.
The key point is that with reading the upgrading guide people will know howto get the old behavior. I do not quite agree that this change is necessary, but I guess the "ALL" in "E_ALL" implies it includes everything, so its logical on that level. regards, Lukas PS: Obviously this will be quite painful for PEAR, but I guess that is partially the point here: create some pains to nudge people towards writing PHP5 only code. Or maybe its just about covering our asses against users who complain about us removing deprecated functionality after a few minor releases.

Marcus Börger

20 years ago
Hello Lukas, Monday, May 15, 2006, 8:43:41 AM, you wrote:
> Derick Rethans wrote: >> On Sun, 14 May 2006, Marcus Boerger wrote: >> >>> That said i am about to not remove E_STRICT from E_ALL and MFH the php >>> 6.0 to item just now. >>> See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry)) >>> >>> Since this is for the benefit of the users to prevent issues with >>> changes in behavior from my opinion it is best to do this behavior >>> change as early as possible, which is in my opinion 5.2 anyway. >>> >>> That said i'll let it in and if there is no valid argument against, i >>> will put it into the NEWS file and the newly started README.UPDATE_5_2. >> >> Yup, I agree on this.
> The key point is that with reading the upgrading guide people will know > howto get the old behavior. I do not quite agree that this change is > necessary, but I guess the "ALL" in "E_ALL" implies it includes > everything, so its logical on that level.
> regards, > Lukas
> PS: Obviously this will be quite painful for PEAR, but I guess that is > partially the point here: create some pains to nudge people towards > writing PHP5 only code. Or maybe its just about covering our asses > against users who complain about us removing deprecated functionality > after a few minor releases.
Sorry i have to say that but PEAR is no argument here as still after years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing a PHP 5 version here. Best regards, Marcus

Lukas Smith

20 years ago
Marcus Boerger wrote: <offtopic>
> Sorry i have to say that but PEAR is no argument here as still after > years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing > a PHP 5 version here.
PEAR is PHP5 compatible. But you probably meant E_STRICT compatible. Yes, I agree that PEAR needs to become once again a place for features missing in PHP and not a place for legacy code. </offtopic> Anyways I brought up PEAR more as an example of what our current userbase looks like. Mostly doing PHP4 and where its PHP5 its often written to also be compatible with PHP4. By increasing the burden on keeping this "duality" we might get more people to make the jump which might put enough pressure on hosters to finally break the chicken and egg situation with PHP5. regards, Lukas

Ron Korving

20 years ago
Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code, where PHP5 features will actually be used and backwards compatibility for PHP4 is lacking. The current PEAR could gradually be ported into this, and PHP4-users can continue to use PEAR (version 1, if you will). Ron "Lukas Smith" <lsmith@php.net> schreef in bericht news:44682CC8.6010200@php.net...

Lukas Smith

20 years ago
Ron Korving wrote:
> Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code, > where PHP5 features will actually be used and backwards compatibility for > PHP4 is lacking. The current PEAR could gradually be ported into this, and > PHP4-users can continue to use PEAR (version 1, if you will).
Maybe. But this is a topic for another list .. regards, Lukas

Pierre Joye

20 years ago
On 5/15/06, Marcus Boerger <helly@php.net> wrote:
> Sorry i have to say that but PEAR is no argument here as still after > years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing > a PHP 5 version here.
This is a pointless argument. First there is php5 only packages. Second you are proposing to change behaviors between two minor releases. This is not something I would like to see in 5.2. It was planed to be done in php 6.0. Your mistake is not a reason to change this plan. --Pierre