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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
__________ NOD32 1.1380 (20060125) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
