[RFC] E_DEPRECATED

Steph

19 years ago

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

Pierre Joye

19 years ago

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_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.

+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

Robert Cummings

19 years ago

On Mon, 2006-10-23 at 21:29 +0200, Pierre wrote:

> 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_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.
>
> +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.          |
`------------------------------------------------------------'

Derick Rethans

19 years ago

On Mon, 23 Oct 2006, Marcus Boerger wrote:

>   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_STRICT any 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_NOTICE or E_WARNING are 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_ALL does not contain E_STRICT or E_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

Edin Kadribasic

19 years ago

Derick Rethans wrote:

>>   . E_STRICT any 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

Todd Ruth

19 years ago

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

19 years ago

On Tue, 24 Oct 2006, Edin Kadribasic wrote:

> Derick Rethans wrote:
> >>   . E_STRICT any 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

Jasper Bryant-Greene

19 years ago

Derick Rethans wrote:

> On Tue, 24 Oct 2006, Edin Kadribasic 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/

Ilia A.

19 years ago

On 23-Oct-06, at 3:08 PM, Marcus Boerger wrote:

> - 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.

+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_STRICT any 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_NOTICE or E_WARNING are 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_ALL does not contain E_STRICT or E_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

Richard Lynch

19 years ago

On Mon, October 23, 2006 2:08 pm, Marcus Boerger wrote:

> 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?

Alan Milnes

19 years ago

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

Edin Kadribasic

19 years ago

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_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_STRICT any 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_NOTICE or E_WARNING are 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_ALL does not contain E_STRICT or E_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

Sebastian Bergmann

19 years ago

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_STRICT any 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_NOTICE or E_WARNING are 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

Wez Furlong

19 years ago

On 10/23/06, Marcus Boerger <helly@php.net> wrote:

>   . 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_STRICT any 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.

Lukas Smith

19 years ago

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

Zeev Suraski

19 years ago

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_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_STRICT any 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_NOTICE or E_WARNING are 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_ALL does not contain E_STRICT or E_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

Mathieu Gagné

19 years ago

Hi,

> 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.

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

Jasper Bryant-Greene

19 years ago

Mathieu Gagné wrote:

>> 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.
>
> 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.

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/

Mathieu Gagné

19 years ago

Hi,

> I would consider this the sysadmin's fault for letting logs grow without
> bounds. Surely you have heard of log rotation?

These was not sysadmin's fault as it was the default Plesk setting.
Logrotate is enabled by default. But as the server was having a huge
load on it, daily logrotations were not enough to limit the overgrow of
logs files.

Just putting my 2 cents as this is problems I had to fixed as a sysadmin.

FYI, every domains have different error_log and access_log files.

--
Mathieu Gagné

Ilia A.

19 years ago

On 24-Oct-06, at 3:22 PM, Mathieu Gagné wrote:

> ]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.

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

Richard Quadling

19 years ago

On 24/10/06, Mathieu Gagné <mgagne@generationphp.net> wrote:
> Hi,
>
>  > 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.
>
> 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.

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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Richard Quadling

19 years ago

My vote (if it counts - can someone let me know if it does?)

On 23/10/06, Marcus Boerger <helly@php.net> 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_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_STRICT any 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_NOTICE or E_WARNING are 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_ALL does not contain E_STRICT or E_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&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Lukas Smith

19 years ago

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 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).

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

19 years ago

On 24/10/06, Lukas Kahwe Smith <lsmith@php.net> wrote:

> 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 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).
>
> 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.

Ah. Oh. Excellent. Didn't know that. Thank you. (Balancing ... balancing ...)

--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Christian Schneider

19 years ago

Marcus Boerger wrote:

> - Add a new severity E_DEPRECATED

Sounds like a good idea, +1 on the whole thing.

>   . E_STRICT any 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

Richard Lynch

19 years ago

On Wed, October 25, 2006 9:56 am, Christian Schneider wrote:

> 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.

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?

Christian Schneider

19 years ago

Richard Lynch wrote:

> On Wed, October 25, 2006 9:56 am, Christian Schneider wrote:
>> 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.
>
> 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

Mike Robinson

19 years ago

Christian Schneider writes:

> 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.

IMHO it's more than just a coding style used to find typos.
It's one of the *nicest* features PHP ever had, and it's a bloody
shame it's gone.


Best Regards

Mike Robinson

Mike Robinson

19 years ago

I myself wrote:

> Christian Schneider writes:
> > 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.
>
> IMHO it's more than just a coding style used to find typos.
> It's one of the *nicest* features PHP ever had, and it's a
> bloody shame it's gone.

Sorry guys, I (thankfully) misunderstood.

Mike

Michael Wallner

19 years ago

Marcus Boerger wrote:

> - 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_STRICT any 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_NOTICE or E_WARNING are 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_ALL does not contain E_STRICT or E_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

[RFC] E_DEPRECATED

Marcus Börger

Steph

Pierre Joye

Robert Cummings

Derick Rethans

Edin Kadribasic

Todd Ruth

Derick Rethans

Jasper Bryant-Greene

Ilia A.

Richard Lynch

Alan Milnes

Edin Kadribasic

Sebastian Bergmann

Wez Furlong

Lukas Smith

Zeev Suraski

Mathieu Gagné

Jasper Bryant-Greene

Mathieu Gagné

Ilia A.

Richard Quadling

Richard Quadling

Lukas Smith

Richard Quadling

Christian Schneider

Richard Lynch

Christian Schneider

Mike Robinson

Mike Robinson

Michael Wallner