Flamewar Summary

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

E_RECOVERABLE_ERROR's apparently going in anyway.
E_STRICT, I'd be all for including into E_ALL now if it weren't for the
'semi-statics' issue (complex) and the distributed INI default settings
(simple). If PEAR:isError() legal doesn't actually do the Engine any harm
then it'd make sense to keep it, purely as a BC consideration, in which case
it shouldn't really need an E_STRICT if the purpose of E_STRICT is to warn
about future BC breaks. Outside that, I personally find E_STRICT useful -
it's helped me diagnose mystery crashes before now - but it's really only
useful if it isn't over-used as an error level.

So -1, and some rethinking needed about the way E_STRICT is used ('this is
the way you should do it' vs 'this is the way you will have to do it in
future')

As far as statics, there are no BC reasons not to do it that I can think
of, but it just seems wrong to me from a design perspective to allow
dynamic creation of static object properties.

It seems very PHP-ish to me to allow it. +1.

• Steph

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
+1

Edin

So, would that make it - non cents?

...sorry, couldn't resist

-D

So please throw in your +1/-1

Darrell Brogdon
darrell@brogdon.net
http://darrell.brogdon.net
http://phpflashcards.com

On Tue, 16 May 2006 19:26:37 -0400
ilia@prohost.org (Ilia Alshanetsky) wrote:

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

-1.

Addition of support for dynamic statics ala: class foo {} foo::$bar =
1;

+1

-- Pierre

Hello Ilia,

Wednesday, May 17, 2006, 1:26:37 AM, you wrote:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1

I gave my best on this. But be sure. I'll just ignore any whining on
any change that has a E_STRICT in older versions when doing changes
in any version after 5.2.

Also before you think removing E_STRICT solves everything; Well it
doesn't.

While doing all the stuff we wanted for 5.2 we also added
E_RECOVERABLE_ERROR. This includes stuff that was E_ERROR before
hand. And right now we didn't even start to systematically convert
all error modes in the extension directory as we started to do in
HEAD.

That said you most likely have to fix your error_reporting anyway or
just don't care at all since you use settings that just work yor you.

An argument i heared was that some applications that deal with
error_reporting might get into trouble with this. I have a solution to
that: we simply revert all the engine changes, or even better simply
rebranch 5.1.4 again and do not do any progress other than fixing bugs
and focusing on PHP 6.0.

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1

If we go that road i suggest we simply drop support for strict. Fixing
the issues we will run into is quite impossible and even if it were it
would lead to a slower php. A php that doesn't support strict at all
would on the other hand be quite a bit faster.

Best regards,
Marcus

p.s: And no, i wouldn't take it personally if someone reverts all my
stuff as long as it is decided by the RM.

I would simply whine for the around 50 hours of unpaid work :-)

-1 on both here, E_STRICT can wait and dynamic static variables are
pretty pointless, the workaround is clearer than the kludge..
StaticClass::$options['somekey'] = 'value';

Regards
Alan

Ilia Alshanetsky wrote:

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

So please throw in your +1/-1 so, that we can have a conclusion on
these matters.

Personally, I am against both changes.

I think the error reporting level change is too major change for a
minor release such as 5.2 and will cause problems for all the people
who use things like E_ALL &~ E_NOTICE and will now
see E_STRICT messages that is not their intent to see, with the
setting they are only anticipating warnings and errors. Given that
most people don't bother to turn of displaying of errors, it could
have an affect on quite a few applications, very few big PHP apps can
run without generating any E_STRICT messages.

As far as statics, there are no BC reasons not to do it that I can
think of, but it just seems wrong to me from a design perspective to
allow dynamic creation of static object properties.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

P.S. Please stay on topic.

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1.

--Wez.

There are 2 PHP 5.2 changes there has been a lot of back and forth flaming
going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

E_RECOVERABLE_ERROR should definitely be there as it's a higher level
than E_WARNING. +1 on adding that to E_ALL.

I don't care about E_STRICT, +0.5 on adding that to E_ALL,

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

I myself don't see the use, but it isn't really bad either. +0.5 on it.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

+1

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

-1, especially for including E_STRICT.

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

Don't care that much, but looks like there are technical reasons for
better not doing that, so -1 here too.

chregu

So please throw in your +1/-1 so, that we can have a conclusion on these
matters.

Personally, I am against both changes.

I think the error reporting level change is too major change for a minor
release such as 5.2 and will cause problems for all the people who use
things like E_ALL &~ E_NOTICE and will now
see E_STRICT messages that is not their intent to see, with the setting
they are only anticipating warnings and errors. Given that most people
don't bother to turn of displaying of errors, it could have an affect on
quite a few applications, very few big PHP apps can run without
generating any E_STRICT messages.

As far as statics, there are no BC reasons not to do it that I can think
of, but it just seems wrong to me from a design perspective to allow
dynamic creation of static object properties.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

P.S. Please stay on topic.

--

--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | christian.stocker@bitflux.ch | GPG 0x5CE1DECB

Ilia Alshanetsky wrote:

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

I don't like E_ALL & ~E_NOTICE suddenly starting to throw E_STRICT in a
minor version upgrade. So I am -1 on that one as well. We agreed to do
this in PHP 6 a while ago. What has changed to move that to 5.x now?

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

I don't really see why we need strictness here. If people want to
redefine their statics on the fly, why get in their way? Of course, I
also don't see why you would want to change the class definition on the
fly like this. And would it change already instantiated objects of that
class as well? So I am not against it assuming the semantics are sane.
+0 I guess.

-Rasmus

Ilia Alshanetsky wrote:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

I do not like the idea of changing the constants in a minor release. I
know "ALL" implies includes everything but I prefer to keep E_ALL like
it is and add an E_PEDANTIC (and default to that in the sample ini files) ..

So -1

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

We are dynamic everywhere. If you do not agree with this, than PHP is
probably not your language. That being said there are several ways to
work around this with defined static arrays or even $GLOBALS, which is
why I never really ran into this issue myself.

Still +1

regards,
Lukas

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

E_RECOVERABLE should stay.
E_STRICT should not.

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1.

--
Wbr,
Antony Dovgal

Ilia Alshanetsky wrote:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

+0

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Ilia Alshanetsky wrote:

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

+1 for E_RECOVERABLE_ERROR as it's been E_ERROR before
-1 for E_STRICT, though

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

+1, half-heartedly

Regards,

Michael

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

+1

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1

I already gave my opinion on that.

So please throw in your +1/-1 so, that we can have a conclusion on
these matters.

Personally, I am against both changes.

I think the error reporting level change is too major change for a
minor release such as 5.2 and will cause problems for all the people
who use things like E_ALL &~ E_NOTICE and will now
see E_STRICT messages that is not their intent to see, with the
setting they are only anticipating warnings and errors. Given that
most people don't bother to turn of displaying of errors, it could
have an affect on quite a few applications, very few big PHP apps can
run without generating any E_STRICT messages.

As far as statics, there are no BC reasons not to do it that I can
think of, but it just seems wrong to me from a design perspective to
allow dynamic creation of static object properties.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

P.S. Please stay on topic.

--

Cyberly yours,
Petar Nedyalkov
Devoted Orbitel Fan :-)

PGP ID: 7AE45436
PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc
PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436

Am Mi, den 17.05.2006 schrieb Ilia Alshanetsky um 1:26:

-1 for E_STRICT in 5.x

/Georg

At 02:26 17/05/2006, Ilia Alshanetsky wrote:

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

-1

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1

Ilia Alshanetsky wrote:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1

Changing the behavior of error reporting can have some implications on
servers where it is intended to not show errors at least with E_STRICT
errors.

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
+1

This would allow for more dynamic code and since in the non static
context it is already allowed I see no reason to not allow it in static
context.

Ilia Alshanetsky wrote:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1

--
Etienne Kneuss

http://www.colder.ch/
colder@php.net

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

I am not glad with E_RECOVERABLE_ERROR at all, but if it went into 5.2 it
should be included into E_ALL, becouse in most cases it substitute E_ERROR
messages.

E_STRICT +0
E_RECOVERABLE_ERROR +1

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1

Thanks. Dmitry.

There are 2 PHP 5.2 changes there has been a lot of back and
forth flaming going around and we need to finally come to a
decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {}
foo::$bar = 1;

E_RECOVERABLE_ERROR +1

As for E_STRICT, am I right in thinking that some E_STRICT warnings are generated by the parser, and before any PHP code is
executed? So using error_reporting(E_ALL & ~E_STRICT) is never going to prevent some E_STRICT warnings?
If so -1, as E_STRICT behaves differently compared to the other E_*s, otherwise 0.

foo::$bar = 1;
-1

Jared

At 04:26 PM 5/16/2006, Ilia Alshanetsky wrote:

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

So please throw in your +1/-1 so, that we can have a conclusion on
these matters.

Personally, I am against both changes.

I second that with two -1's.

Andi

I think the error reporting level change is too major change for a
minor release such as 5.2 and will cause problems for all the people
who use things like E_ALL &~ E_NOTICE and will now
see E_STRICT messages that is not their intent to see, with the
setting they are only anticipating warnings and errors. Given that
most people don't bother to turn of displaying of errors, it could
have an affect on quite a few applications, very few big PHP apps can
run without generating any E_STRICT messages.

As far as statics, there are no BC reasons not to do it that I can
think of, but it just seems wrong to me from a design perspective to
allow dynamic creation of static object properties.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

P.S. Please stay on topic.

Bonsoir
Ilia Alshanetsky wrote:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-0
I don't like it , but we can easily get over.

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1
We rarely use it, and I think alan's way is ok for those using it massively.
So better restrict that.

I vote in the name of poor hosted people , eventually using trusted
projects.

toggg

There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.

The two topics are:

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

+1 for E_RECOVERABLE_ERROR
-1 for E_STRICT

Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;

-1

-bok

--
Xnyo - http://xnyo.odynia.org/

Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

-0.5

Addition of support for dynamic statics ala: class foo {} foo::$bar =
1;

+1

--
Like Music?
http://l-i-e.com/artists.htm