Flamewar Summary

Edin Kadribasic

20 years ago

> 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

Darrell Brogdon

20 years ago

So, would that make it - non cents?

...sorry, couldn't resist

-D

On May 16, 2006, at 5:26 PM, Ilia Alshanetsky wrote:

> So please throw in your +1/-1

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

Pierre Joye

20 years ago

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

Marcus Börger

20 years ago

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

Marcus Börger

20 years ago

Hello Ilia,

second try of second part this time using static. I guess i need sleep.

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

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

Ilia A.

20 years ago

On 16-May-06, at 7:50 PM, Marcus Boerger wrote:

> Hello Ilia,
>
> Wednesday, May 17, 2006, 1:26:37 AM, you wrote:
>
>> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
> +1
> 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.
>

This can stay as it does not impact on the operation of existing
application and is actually required, otherwise previously fatal
errors will be bypassed.

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

Even if you were to release a new version of software today in
anticipation of a the 5.2 release few months down the road most of
your users will still use old versions while their ISP may have
already upgraded their PHP.

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

I don't think anyone is suggesting that we revert everything, but we
do need to work on minimizing the impact of our changes on our users
in minor releases.


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

Alan Knowles

20 years ago

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

Wez Furlong

20 years ago

On 5/16/06, Ilia Alshanetsky <ilia@prohost.org> 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.

--Wez.

Derick Rethans

20 years ago

On Tue, 16 May 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

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

Brian Moon

20 years ago

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

Christian Stocker

20 years ago

On 17.5.2006 1:26 Uhr, 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, 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.
>
> --PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

Rasmus Lerdorf

20 years ago

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

20 years ago

On 17-May-06, at 2:10 AM, Rasmus Lerdorf wrote:

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

Marcus accidentally made the change as part of this massive overhaul
that was committed as one block, it was not part of the initial plan
for 5.2 that was drawn up.


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

Lukas Smith

20 years ago

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

Antony Dovgal

20 years ago

On 17.05.2006 03:26, 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

E_RECOVERABLE should stay.
E_STRICT should not.

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

-1.

--
Wbr,
Antony Dovgal

Sebastian Bergmann

20 years ago

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

Sebastian Bergmann

20 years ago

Sebastian Bergmann wrote:

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

Apparently I had the wrong context when I read a posting by Marcus on
technical issues (slowdown).

If there are no technical issues with implementing this, then I am -0
on this.

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

Marcus Börger

20 years ago

Hello Sebastian,

there is a technical issue besides slowdown. We have to work around the
fact that suddenly a function might get $this as a normal variable (remember
the examples give on this list included that). Right now $this is handled by
a special zval not stored in the local or global symol table bit EG(this).
This will become a major maintanance hell. Also allowing $this as normal
variable again will confuse people because suddenly after 5.1 they are
under some circumstances suddenly able to change $this. That said, we will
also get a bunch of new bug reports, but who cares, it's the others dealing
with them. And all for what? to refuse using globals as they are to
php'isch? or to use an array in a declared sttaic variable as that can
already be done and is also far to php'ish?

best regards
marcus

Wednesday, May 17, 2006, 10:10:11 AM, you wrote:

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

>  Apparently I had the wrong context when I read a posting by Marcus on
>  technical issues (slowdown).

>  If there are no technical issues with implementing this, then I am -0
>  on this.

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

Best regards,
Marcus

Richard Lynch

20 years ago

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

On Wed, May 17, 2006 2:03 pm, Marcus Boerger wrote:

>   there is a technical issue besides slowdown. We have to work around
> the
> fact that suddenly a function might get $this as a normal variable
> (remember
> the examples give on this list included that). Right now $this is
> handled by
> a special zval not stored in the local or global symol table bit
> EG(this).
> This will become a major maintanance hell. Also allowing $this as
> normal
> variable again will confuse people because suddenly after 5.1 they are
> under some circumstances suddenly able to change $this. That said, we
> will
> also get a bunch of new bug reports, but who cares, it's the others
> dealing
> with them. And all for what? to refuse using globals as they are to
> php'isch? or to use an array in a declared sttaic variable as that can
> already be done and is also far to php'ish?

I'm not sure it helps, or even if I understand the problem, but
perhaps...

A reasonable compromise might be that only scalars could be used for a
late-binding static foo::$bar = VALUE;

Similar to what is (used to be?) allow for variable initialization
within a class definition.

Or, perhaps, scalars and arrays of scalars allowed, but NO OBJECTS.

It seems like the majority of people who find this late-binding static
stuff useful are not really wanting to cram instance references, much
less $this into there...

This presumes that whatever was done for class property initialization
could be readily repeated at the junction of an assignment to a static
property, which might be a completely incorrect assumption.

This is also post-vote, which might render it meaningless, which is
fine  -- just an idea if the vote is inconclusive or turns out to be
void.

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

Marcus Börger

20 years ago

Hello Richard,

well my mail was a bit out of context or at the wrong reply to Sebastian.
He was talking about issues with callin static functions with bypassing
$this as a parameter....

best regards
marcus

Friday, May 19, 2006, 12:22:36 AM, you wrote:

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

> On Wed, May 17, 2006 2:03 pm, Marcus Boerger wrote:
>>   there is a technical issue besides slowdown. We have to work around
>> the
>> fact that suddenly a function might get $this as a normal variable
>> (remember
>> the examples give on this list included that). Right now $this is
>> handled by
>> a special zval not stored in the local or global symol table bit
>> EG(this).
>> This will become a major maintanance hell. Also allowing $this as
>> normal
>> variable again will confuse people because suddenly after 5.1 they are
>> under some circumstances suddenly able to change $this. That said, we
>> will
>> also get a bunch of new bug reports, but who cares, it's the others
>> dealing
>> with them. And all for what? to refuse using globals as they are to
>> php'isch? or to use an array in a declared sttaic variable as that can
>> already be done and is also far to php'ish?

> I'm not sure it helps, or even if I understand the problem, but
> perhaps...

> A reasonable compromise might be that only scalars could be used for a
> late-binding static foo::$bar = VALUE;

> Similar to what is (used to be?) allow for variable initialization
> within a class definition.

> Or, perhaps, scalars and arrays of scalars allowed, but NO OBJECTS.

> It seems like the majority of people who find this late-binding static
> stuff useful are not really wanting to cram instance references, much
> less $this into there...

> This presumes that whatever was done for class property initialization
> could be readily repeated at the junction of an assignment to a static
> property, which might be a completely incorrect assumption.

> This is also post-vote, which might render it meaningless, which is
> fine  -- just an idea if the vote is inconclusive or turns out to be
> void.

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

Best regards,
Marcus

Michael Wallner

20 years ago

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

Ford, Mike [LSS]

20 years ago

Ilia Alshanetsky wrote:

> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

-1/+1
E_RECOVERABLE_ERROR has to be in as it's taken over some previously E_ERROR situations.
It's probably too soon for E_STRICT right now, although it should be enabled in some 5.x.0 release (with sufficient fanfare!).

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

-0

---------------------------------------------------------------------
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS,  LS6 3QS,  United Kingdom
Email: m.ford@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730      Fax:  +44 113 283 3211


To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

Petar Nedyalkov

20 years ago

On Wednesday 17 May 2006 02:26, 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

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

Georg Richter

20 years ago

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

-1 for E_STRICT in 5.x

/Georg

Zeev Suraski

20 years ago

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

Zeev Suraski

20 years ago

At 12:23 17/05/2006, Zeev Suraski wrote:

>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

I have to say I changed my mind about E_RECOVERABLE_ERROR - I think
it should be a part of E_ALL.  Not so about E_STRICT in 5.2.

Zeev

Mark Sanders

20 years ago

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.

Etienne Kneuss

20 years ago

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

Dmitry Stogov

20 years ago

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

Steph

20 years ago

> 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

Steph

20 years ago

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

Going on from there - if E_STRICT is now being touted as 'deprecated stuff
only', would it be a good idea to have something like E_DEVEL for 'advice'
issues like vars, semi-statics, etc etc etc - which would of course _never_
become part of E_ALL? Or was that the original intention for E_NOTICE?

Just a thought.

- Steph

Jared Williams

20 years ago

> 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

Andi Gutmans

20 years ago

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

bertrand Gugger

20 years ago

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

Robert Amos

20 years ago

On 5/17/06, Ilia Alshanetsky <ilia@prohost.org> 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 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/

Richard Lynch

20 years ago

On Tue, May 16, 2006 6:26 pm, Ilia Alshanetsky wrote:

> 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

Jasper Bryant-Greene

20 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Tue, May 16, 2006 6:26 pm, Ilia Alshanetsky wrote:

> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL

I'd say E_RECOVERABLE_ERROR has to go into E_ALL as it was effectively
there previously, as part of E_ERROR. So +1 there.
As far as E_STRICT goes: +/- 0

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

+1

- --
Jasper Bryant-Greene
General Manager
Album Limited

http://www.album.co.nz/     0800 4 ALBUM
jasper@album.co.nz          021 708 334
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEbPBsFfAeHhDzT4gRAzk3AKDUAdKPt7Vk5c+2X9buain2aA5gHgCg4vIQ
ZwRV3/1WgI3Ho0QQGrzeibM=
=VF4M
-----END PGP SIGNATURE-----