Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
-
Add a new severity
E_DEPRECATED -
severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
.E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g. domain errors). -
We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED -
We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
You may respond with constructive ideas or complaints or go voting for all
or single points here, use -1, 0, +1 only. Please do not reply for the sake
of responding, use pure voting instead as we are running out of time for
5.2.0 otherwise.
Best regards,
Marcus
Hi Marcus,
+1 to everything here if it counts, but please can you simplify the role of
E_DEPRECATED by making it 'next major version only'? I can see all kinds of
problems with leaving that open to debate.
- Steph
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
.E_STRICTany rule that reflects common strict standards, like OOP
theory
that is considered harmless if not followed. For example the
combination
'abstract static' makes no sense in said theory but doesn't put our
zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g. domain
errors).We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATEDWe delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.You may respond with constructive ideas or complaints or go voting for all
or single points here, use -1, 0, +1 only. Please do not reply for the
sake
of responding, use pure voting instead as we are running out of time for
5.2.0 otherwise.Best regards,
Marcus
On Mon, 23 Oct 2006 21:08:57 +0200
helly@php.net (Marcus Boerger) wrote:
Hello internals,
after recent discussions (over the last three months)I finally made
up my mind over E_STRICT, deprecation warnings and OOP
messages/rules. My idea proposal is to do the following:
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst removal would be two minor versions or one major version
later. That is something that gets deprecated in 5.2 can be removed
in 5.4.0 or 6.0.0. However both marking it as deprecated as well as
removing it would require a consensus on the list.
+1 If removed in the next major version only. -1 otherwise.
It is already a nightmare to remember or manage the various changes in
all last minor releases.
You may respond with constructive ideas or complaints or go voting
for all or single points here, use -1, 0, +1 only. Please do not
reply for the sake of responding, use pure voting instead as we are
running out of time for 5.2.0 otherwise.
+1 for the other points, even if we can expect 5.2.0 for early 2007 ;-)
-- Pierre
On Mon, 23 Oct 2006 21:08:57 +0200
helly@php.net (Marcus Boerger) wrote:Hello internals,
after recent discussions (over the last three months)I finally made
up my mind over E_STRICT, deprecation warnings and OOP
messages/rules. My idea proposal is to do the following:
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst removal would be two minor versions or one major version
later. That is something that gets deprecated in 5.2 can be removed
in 5.4.0 or 6.0.0. However both marking it as deprecated as well as
removing it would require a consensus on the list.+1 If removed in the next major version only. -1 otherwise.
+1 with same sentiments.
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- Add a new severity
E_DEPRECATED
+1
- severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
+1
.
E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
+1, but then we should also expand this to include:
- setting object variables without declaring them
- auto-creating objects of stdclass on the fly
- and other things that you *should* (not) do
These can be added later ofcourse, doesn't have to be directly in
5.2.0, however that would probably be better.
.
E_NOTICEorE_WARNINGare used for input validations (e.g. domain errors).
+1, but I think we need to specify when exactly to use E_NOTICE,
E_WARNING, E_RECOVERABLE_ERROR and E_ERROR as well.
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED
-1, We should include E_DEPRECATED in E_ALL.
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+1
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
.
E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.+1, but then we should also expand this to include:
- setting object variables without declaring them - auto-creating objects of stdclass on the fly - and other things that you *should* (not) do These can be added later ofcourse, doesn't have to be directly in 5.2.0, however that would probably be better.
I'm -1 on expanding strictness to this. I don't understand why you
should not do this? Writing mydb_fetch_object() becomes impossible in
userspace if we go this far. It would also make any legal use of
stdClass impossible.
Edin
I'm not a voter, but I'd like to lobby for a fancier
E_STRICT...
E_STRICT is sounding more and more like runtime "lint".
I very much miss lint. (I'm sure it's still around, but
I've been programming in only php for the last few years.)
A key feature of lint that made it usable was that you
could have a file listing error codes that you always
wanted to ignore and you could use a comment adjacent to
your "bad" code to tell lint to ignore that specific
case. I think a previous thread talked about using codes
in the messages to allow easy bulk filtering, so the
file of codes to skip isn't absolutely necessary. Being
able to put in a comment that causes the E_STRICT to
be skipped for an adjacent bit of "bad" code would be
very friendly. We make sure all of our code is NOTICE
free (for as many code paths as we can stand to test)
before it goes out the door. I'm sure many others do
the same. To be able to do the same with E_STRICT would
be a great benefit, but I think a larger portion of the
user base would adopt it if there were ways to turn down
the volume when you really want to ignore "the guidelines
for ideal code". I have no idea how difficult such a
feature would be; I just wanted to point out how useful
it would be. (As always, thanks for all that all of you
do!)
BTW, the trend on the list toward separating STRICT
and DEPRECATED and only putting deadly stuff in the
DEPRECATED bin is very much appreciated. For a while
I was guessing we'd never be able to upgrade our php!
I'm still assuming 5.2 is unusable based on the threads
about fatal errors, but it seems all this will be sorted
out for 5.3 at the latest. That's better than being
on 5.1 for the rest of our lives.
Thanks,
Todd
Derick Rethans wrote:
.
E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.+1, but then we should also expand this to include:
- setting object variables without declaring them - auto-creating objects of stdclass on the fly - and other things that you *should* (not) do These can be added later ofcourse, doesn't have to be directly in 5.2.0, however that would probably be better.I'm -1 on expanding strictness to this. I don't understand why you
should not do this?
Because atleast those two points should usually never happen in a
serious application. They're very often just typoes and make debugging
harder. As I know you don't care about that, simply don't turn on
E_STRICT...
Writing mydb_fetch_object() becomes impossible in
userspace if we go this far. It would also make any legal use of
stdClass impossible.
Yes, but in the "strict" world, there is no legal use for stdClass in
the first place.
regards,
Derick
Derick Rethans wrote:
Writing mydb_fetch_object() becomes impossible in
userspace if we go this far. It would also make any legal use of
stdClass impossible.Yes, but in the "strict" world, there is no legal use for stdClass in
the first place.
I've got to agree with this and Derick's other points. I've written or
been involved in writing a great many larger PHP applications, all of
which have aimed to be E_STRICT clean, and have never, ever used stdClass.
I can't see a reason why you would want to, as it's effectively an
associative array with syntax that fools people into thinking you're
writing OO code :>
As to mydb_fetch_object()... what was wrong with mydb_fetch_assoc()?
What does mydb_fetch_object() add to it other than aforementioned syntax
that pretends to be OO?
--
Jasper Bryant-Greene
Director
Album Limited
jasper@albumltd.co.nz
+64 21 708 334 / 0800 425 286
http://www.albumltd.co.nz/
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst
removal would be two minor versions or one major version later.
That is
something that gets deprecated in 5.2 can be removed in 5.4.0
or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
+1 as long as a removal is set, not the "we may or may not remove
this, but here is a warning anyway". Once a component is marked with
E_DEPRECATED, the next major release it is out.
.
E_STRICTany rule that reflects common strict standards, like
OOP theory
that is considered harmless if not followed. For example the
combination
'abstract static' makes no sense in said theory but doesn't put
our zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g.
domain errors).
-1 In this case it seems like a pointless error level to me just
killing cycles. If you are not using questionable behavior that has
side-effects, why bother the user?
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|
E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED
Rename rather then drop.
- We delay 5.2.0 and revisit all errors and change them according
to the
new model. We also put any change into the upgrading file.
-1 (not happening)
Ilia Alshanetsky
Hello internals,
+1, ditto on only major version for E_DEPRECATED to disappear
I'd go either way on E_ALL changing -- but would think that the Right
Thing is to leave it alone in 5.2, but make it mean ALL (even
E_STRICT) in 6.0
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
+1 to them all.
Alan
Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
.E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g. domain errors).
+1
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED
+1
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+1
You may respond with constructive ideas or complaints or go voting for all
or single points here, use -1, 0, +1 only. Please do not reply for the sake
of responding, use pure voting instead as we are running out of time for
5.2.0 otherwise.Best regards,
Marcus
Edin
Marcus Boerger wrote:
- Add a new severity
E_DEPRECATED
+1
- severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
.E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g. domain errors).
+1
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+1
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
. E_DEPRECATED: Some language featre that is likely to go away.
s/likely/confirmed/. We can't speculatively deprecate a feature and
then change our minds. (The {} vs [] thing with strings comes to
mind).
I don't think we need to set any firm ground rules for the deprecation
timeline but should consider each change individually. A reasonable
rule of thumb is to remove deprecated features no sooner than 1 minor
release after the deprecation notice was added. Ideally, it should be
in a major release.
+1
.
E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
+1
Note that if we are going to treat implicit property setting as
E_STRICT then we should exclude stdClass from generating those
warnings, otherwise you can't work with deliberately created dynamic
objects.
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+0.
Let's just delay 5.2 long enough to make sure we haven't accidentally
promoted E_STRICT to fatal errors in 5.2.
--Wez.
Wez Furlong wrote:
I don't think we need to set any firm ground rules for the deprecation
timeline but should consider each change individually. A reasonable
rule of thumb is to remove deprecated features no sooner than 1 minor
release after the deprecation notice was added. Ideally, it should be
in a major release.
I think we should have a firm rule, such as:
At every major version we grep through the code base for stuff marked as
deprecated and if there is not a really really good reason someone comes
up with its out. Any rule should be superseded by common sense anyways.
regards,
Lukas
At 21:08 23/10/2006, Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
.E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g.
domain errors).
+1
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED
-1
I don't think we should change the names. A bunch of the
-recommended changes from the default file have nothing to do with
development/production, so differentiating based on that is not
accurate. Avoiding renames will also reduce the chance of confusion
(no big deal, but even the tiniest changes in such a central piece
tend to trigger questions).
I personally also don't see a good reason to disable E_WARNING and
E_NOTICE (and possibly also E_DEPRECATED) in a production environment
- you may still want to log such errors. As long as display_errors
is off, it's not a problem except for the performance hit which
should be low assuming you don't have too many of them.
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+1
Zeev
Hi,
I personally also don't see a good reason to disable
E_WARNINGand
E_NOTICE(and possibly also E_DEPRECATED) in a production environment -
you may still want to log such errors. As long as display_errors is
off, it's not a problem except for the performance hit which should be
low assuming you don't have too many of them.
As a system administrator, I must disagree with your opinion as most
users don't care about error_log file. I have see a lot of servers with
about 6GB of error_log filled with E_NOTICE AND E_WARNING.
Just letting it enabled by default in production is a bad idea. Those
notices should only be enabled during development since production is no
more the time to do such debugging.
--
Mathieu
Mathieu Gagné wrote:
I personally also don't see a good reason to disable
E_WARNINGand
E_NOTICE(and possibly also E_DEPRECATED) in a production environment -
you may still want to log such errors. As long as display_errors is
off, it's not a problem except for the performance hit which should be
low assuming you don't have too many of them.As a system administrator, I must disagree with your opinion as most
users don't care about error_log file. I have see a lot of servers with
about 6GB of error_log filled withE_NOTICEAND E_WARNING.
I would consider this the sysadmin's fault for letting logs grow without
bounds. Surely you have heard of log rotation?
Just letting it enabled by default in production is a bad idea. Those
notices should only be enabled during development since production is no
more the time to do such debugging.
If you have debugged your code well, and got rid of all the
E_WARNING/E_NOTICE that you can, then surely you would want to know if a
new one crops up? I see no problem with having E_WARNING/E_NOTICE enabled.
E_DEPRECATED is another thing though. Enabling this by default is good
because you will notice when code you are using becomes deprecated.
However it probably shouldn't be enabled in production as you should be
upgrading PHP on a development/testing/staging system before you do so
on a live server!
--
Jasper Bryant-Greene
Director
Album Limited
jasper@albumltd.co.nz
+64 21 708 334 / 0800 425 286
http://www.albumltd.co.nz/
]As a system administrator, I must disagree with your opinion as
most users don't care about error_log file. I have see a lot of
servers with about 6GB of error_log filled withE_NOTICEAND
E_WARNING.
Many ISPs often make 2 mistakes when it comes to log files. First
they make all users use the same one, which means you potentially
have hundreds of applications dumping errors into the same file
making it grow quickly and impossible to find something in it. Which
discourages users from looking in those files. The second mistake is
often not giving the users access to the file or simply not letting
them know where such a file can be found.
Ilia Alshanetsky
Hi,
I personally also don't see a good reason to disable
E_WARNINGand
E_NOTICE(and possibly also E_DEPRECATED) in a production environment -
you may still want to log such errors. As long as display_errors is
off, it's not a problem except for the performance hit which should be
low assuming you don't have too many of them.As a system administrator, I must disagree with your opinion as most
users don't care about error_log file. I have see a lot of servers with
about 6GB of error_log filled withE_NOTICEAND E_WARNING.Just letting it enabled by default in production is a bad idea. Those
notices should only be enabled during development since production is no
more the time to do such debugging.
As I run my own servers, I'm forgetful of the laziness of some ISPs.
So, yes I can see that having them enabled COULD be considered a bad
thing, BUT again, it is education to train people to write code which
doesn't produce WENDS (Warnings/Errors/Notices/Deprecated/Strict).
And for those lazy ISPs, it will make little difference what the
setting is anyway. If they have a 6GB error file now, then having one
a little bigger really isn't that much of concern.
The benefit though is that WENDS can still be generated in a
production environment and I would sure as hell want to see them in a
log file. Often the production environment is not 100% identical to
the development environment (different memory, speed, loading, etc).
Or to paraphase Forrest Gump, "Shit Happens!".
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
My vote (if it counts - can someone let me know if it does?)
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- Add a new severity
E_DEPRECATED
+1 - Absolutely.
- severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
+1 - At a major release would seem more appropriate, though
deprecating something near the end of the previous major release could
seem to be too quick.
.
E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
+1 - As an aside, it would be extremely useful to have the PEAR
classes marked as NON strict (in some way) until they are. I know this
is outside of the core, but using E_STRICT already means you have to
toggle off E_STRICT for PEAR. MAYBE STRICT (e.g. strict class PEAR
{...}) as a new keyword for a class, just so that you know that it IS
strict (or at least expecting to be).
.
E_NOTICEorE_WARNINGare used for input validations (e.g. domain errors).
+1/0 - Is this any different to what we already have?
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED
-1 : As mentioned, if the developed code is notice/strict clean (and
it sure as hell should be), then the only major difference is
displaying of errors. The use of error and exception handlers should
be promoted to reduce the requirement of hiding errors.
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
-1 : Whilst I would like to have everything and the kitchen sink in
PHP (I've got one in FireFox - actually doesn't make it any better
though), the longer the delay, the more problems there seems to be.
Have the cut off and fix faster! (Ok - that's just me being funny. Or
not! You are all working VERY hard to get this working for us, well,
me and all I do is make bad comments - but hey! Ain't open source
great? Community spirit and all that! Everyone chipping in with their
2cents worth ...)
You may respond with constructive ideas or complaints or go voting for all
or single points here, use -1, 0, +1 only. Please do not reply for the sake
of responding, use pure voting instead as we are running out of time for
5.2.0 otherwise.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Richard Quadling wrote:
+1 - As an aside, it would be extremely useful to have the PEAR
classes marked as NON strict (in some way) until they are. I know this
is outside of the core, but usingE_STRICTalready means you have to
toggle offE_STRICTfor PEAR. MAYBE STRICT (e.g. strict class PEAR
{...}) as a new keyword for a class, just so that you know that it IS
strict (or at least expecting to be).
heh .. no that would not be useful .. it would be lying. PEAR already
has decided on an RFC that will mandate PHP5 only for new packages soon.
Also PEAR mandates E_STRICT compliance for PHP5 only packages. So time
will fix this issue.
regards,
Lukas
Richard Quadling wrote:
+1 - As an aside, it would be extremely useful to have the PEAR
classes marked as NON strict (in some way) until they are. I know this
is outside of the core, but usingE_STRICTalready means you have to
toggle offE_STRICTfor PEAR. MAYBE STRICT (e.g. strict class PEAR
{...}) as a new keyword for a class, just so that you know that it IS
strict (or at least expecting to be).heh .. no that would not be useful .. it would be lying. PEAR already
has decided on an RFC that will mandate PHP5 only for new packages soon.
Also PEAR mandatesE_STRICTcompliance for PHP5 only packages. So time
will fix this issue.
Ah. Oh. Excellent. Didn't know that. Thank you. (Balancing ... balancing ...)
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Marcus Boerger wrote:
- Add a new severity
E_DEPRECATED
Sounds like a good idea, +1 on the whole thing.
.
E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
Another idea (I haven't seen skimming through the replies):
Move use of undefined variable, property and index from E_NOTICE to
E_STRICT as it is a coding style question some people use to find typos.
Regards,
- Chris
Another idea (I haven't seen skimming through the replies):
Move use of undefined variable, property and index fromE_NOTICEto
E_STRICTas it is a coding style question some people use to find
typos.
I'd be totally -1 on that...
Using un-initialized variables will lead the newbie scripter into all
kinds of problems if you don't break that habit while they are
young...
I think php.ini default should have E_NOTICE "on" and have said so
since version 4.x, maybe even 3.x
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch wrote:
Another idea (I haven't seen skimming through the replies):
Move use of undefined variable, property and index fromE_NOTICEto
E_STRICTas it is a coding style question some people use to find
typos.I'd be totally -1 on that...
Using un-initialized variables will lead the newbie scripter into all
kinds of problems if you don't break that habit while they are
young...I think php.ini default should have
E_NOTICE"on" and have said so
since version 4.x, maybe even 3.x
Make E_STRICT on by default and you'd have the same "newbie-protection".
But that's an independent question (default error reporting level).
Uninitialized variables IMHO fall exactly into the same category as
OO-non-strictness: Some people consider the comfort factor worth the
added risk of not catching a typo.
So it's not about having the feature of reporting uninitialized
variables or not, it's just about what error level to assign to it.
My two cents,
- Chris
Marcus Boerger wrote:
Add a new severity
E_DEPRECATEDseverities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
removal would be two minor versions or one major version later. That is
something that gets deprecated in 5.2 can be removed in 5.4.0 or 6.0.0.
However both marking it as deprecated as well as removing it would
require a consensus on the list.
.E_STRICTany rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no sense in said theory but doesn't put our zend
engine in an unstable state.
.E_NOTICEorE_WARNINGare used for input validations (e.g. domain errors).
+1
- We drop the current standard INI files and provide two new, namely
. php-develop.ini for developing (E_ALL|E_STRICT|E_DEPRECATED)
. php-production.ini for production (~(E_DEPRECATED|E_NOTICE|E_WARNING))
.E_ALLdoes not containE_STRICTorE_DEPRECATED
0
- We delay 5.2.0 and revisit all errors and change them according to the
new model. We also put any change into the upgrading file.
+1
Regards,
Michael