# E_ALL changes in 5.2/6.0
- Thread: https://externals.io/message/23342
- Original archive: https://news-web.php.net/php.internals/23342
- Started by Marcus Boerger on 2006-05-14T18:59:03+00:00
- Messages: 91
- Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/23342.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #23352 — Steph Fox — 2006-05-14T01:49:40+00:00
URL: https://externals.io/message/23342#23352 · In reply to: #23342
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 :\
> 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
>
> --
>
>
>
>
> __________ NOD32 1.1380 (20060125) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
---
## #23378 — Steph Fox — 2006-05-14T16:31:10+00:00
URL: https://externals.io/message/23342#23378 · In reply to: #23368
> > […]
>
> 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
---
## #23402 — Steph Fox — 2006-05-14T18:45:33+00:00
URL: https://externals.io/message/23342#23402 · In reply to: #23400
> 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
---
## #23342 — Marcus Boerger — 2006-05-14T18:59:03+00:00
URL: https://externals.io/message/23342#23342
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
---
## #23350 — Pierre — 2006-05-15T00:39:02+00:00
URL: https://externals.io/message/23342#23350 · In reply to: #23342
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
---
## #23442 — Steph Fox — 2006-05-15T03:56:55+00:00
URL: https://externals.io/message/23342#23442 · In reply to: #23440
At 11:49 AM 5/15/2006, Brian Moon wrote:
> > […]
>
> "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
---
## #23353 — Derick Rethans — 2006-05-15T06:16:40+00:00
URL: https://externals.io/message/23342#23353 · In reply to: #23342
> 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
---
## #23354 — Lukas Smith — 2006-05-15T06:43:41+00:00
URL: https://externals.io/message/23342#23354 · In reply to: #23353
Derick Rethans wrote:
>
>
> > […]
>
> 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.
---
## #23356 — Marcus Boerger — 2006-05-15T07:01:28+00:00
URL: https://externals.io/message/23342#23356 · In reply to: #23354
Hello Lukas,
Monday, May 15, 2006, 8:43:41 AM, you wrote:
> Derick Rethans wrote:
> > […]
> 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
---
## #23357 — Marcus Boerger — 2006-05-15T07:13:53+00:00
URL: https://externals.io/message/23342#23357 · In reply to: #23350
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:
> > […]
> 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.
> > […]
> 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.
> > […]
> 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
---
## #23358 — Lukas Smith — 2006-05-15T07:24:56+00:00
URL: https://externals.io/message/23342#23358 · In reply to: #23356
Marcus Boerger 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.
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.
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
---
## #23359 — Ron Korving — 2006-05-15T09:31:06+00:00
URL: https://externals.io/message/23342#23359 · In reply to: #23358
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" schreef in bericht
news:44682CC8.6010200@php.net...
> Marcus Boerger wrote:
>
>
> > […]
>
> 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.
>
>
> 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
---
## #23360 — Lukas Smith — 2006-05-15T09:36:01+00:00
URL: https://externals.io/message/23342#23360 · In reply to: #23359
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
---
## #23362 — Pierre — 2006-05-15T10:29:22+00:00
URL: https://externals.io/message/23342#23362 · In reply to: #23356
> 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
---
## #23363 — Greg Beaver — 2006-05-15T10:51:16+00:00
URL: https://externals.io/message/23342#23363 · In reply to: #23352
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
---
## #23364 — Ilia Alshanetsky — 2006-05-15T13:14:48+00:00
URL: https://externals.io/message/23342#23364 · In reply to: #23363
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.
> Steph Fox 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.
>
> 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 Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org
---
## #23365 — Derick Rethans — 2006-05-15T13:16:53+00:00
URL: https://externals.io/message/23342#23365 · In reply to: #23364
> 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
---
## #23366 — Ilia Alshanetsky — 2006-05-15T13:23:18+00:00
URL: https://externals.io/message/23342#23366 · In reply to: #23365
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.
>
>
> > […]
>
> Then when do you suggest we add it (before 6.0)?
>
> regards,
> Derick
>
Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org
---
## #23368 — Brian Moon — 2006-05-15T14:41:16+00:00
URL: https://externals.io/message/23342#23368 · In reply to: #23352
> 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 =)
---
## #23371 — Todd Ruth — 2006-05-15T16:03:14+00:00
URL: https://externals.io/message/23342#23371 · In reply to: #23363
...
> 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
---
## #23380 — Brian Moon — 2006-05-15T16:40:58+00:00
URL: https://externals.io/message/23342#23380 · In reply to: #23378
> 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 =)
---
## #23396 — Marcus Boerger — 2006-05-15T18:25:10+00:00
URL: https://externals.io/message/23342#23396 · In reply to: #23380
Hello Brian,
Monday, May 15, 2006, 6:40:58 PM, you wrote:
> > […]
> 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
---
## #23397 — Marcus Boerger — 2006-05-15T18:27:14+00:00
URL: https://externals.io/message/23342#23397 · In reply to: #23371
Hello Todd,
Monday, May 15, 2006, 6:03:14 PM, you wrote:
>
> ...
> > […]
> 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?
---
## #23399 — Marcus Boerger — 2006-05-15T18:35:00+00:00
URL: https://externals.io/message/23342#23399 · In reply to: #23366
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...
>
> > […]
> Ilia Alshanetsky
> Advanced Internet Designs Inc.
> ilia@prohost.org
Best regards,
Marcus
---
## #23400 — Marcus Boerger — 2006-05-15T18:40:40+00:00
URL: https://externals.io/message/23342#23400 · In reply to: #23363
Hello Greg,
Monday, May 15, 2006, 12:51:16 PM, you wrote:
> Steph Fox 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.
> 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
---
Next page: https://externals.io/message/23342.md?page=2