Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81305
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54C8BE99.8070109@gmail.com>
References: <54C80F4F.7020905@gmail.com>
	<011d01d03ab7$dd725c30$98571490$@tekwire.net>
	<CAH-PCH7UstXaV67S141fNxpTMyEwChZs5u9NaY3x53JBgqk3WQ@mail.gmail.com>
	<54C8BE99.8070109@gmail.com>
Date: Wed, 28 Jan 2015 13:13:40 +0100
Message-ID: <CAH-PCH7fDygM17XVPTeiEfccsQX0oH0Ui5C_mYN=_9osvzQGVw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044287c049c583050db54d44
Subject: Re: [PHP-DEV] Proposal: Raise severity of undefined constants
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d044287c049c583050db54d44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 28, 2015 at 11:48 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Ferenc Kovacs wrote on 28/01/2015 07:20:
>
>>
>>
>> 2015.01.28. 6:04 ezt =C3=ADrta ("Fran=C3=A7ois Laupretre" <francois@tekw=
ire.net
>> <mailto:francois@tekwire.net>>):
>> >
>> > > De : Rowan Collins [mailto:rowan.collins@gmail.com <mailto:
>> rowan.collins@gmail.com>]
>> > > I would like to propose that the error given for an undefined consta=
nt
>> > > should be raised from E_NOTICE, probably to E_RECOVERABLE_ERROR, in
>> > > PHP 7.
>> >
>> > +1
>> >
>>
>> I don't like that.
>> Depending if we want to keep the behavior on the long term I would eithe=
r
>> go with E_WARNING or E_DEPRECATED
>> Turning it into E_RECOVERABLE_ERROR would be for most users just as bad
>> as removing it while we still have to support the behavior so no real ga=
in
>> for us.
>>
>>
> E_DEPRECATED is likely to be even more ignored than E_NOTICE, so would be
> a step backwards; my whole assumption is that most people getting the
> message are not using a deprecated feature, but accidentally mis-typing a
> constant or keyword. I'd be happy with raising it to E_WARNING to make it
> more noticeable, though, if we don't think removing the functionality is
> acceptable.
>
>
turn it into E_WARNING if we are planning to keep the feature, turn it into
E_DEPRECATED if we want to remove the feature later on.


> On the other hand, if the concern is having to support it, then it could
> just be E_ERROR. The reason I chose E_RECOVERABLE_ERROR is because that h=
ad
> recently been adopted for other things, such as invalid method calls. As =
I
> mentioned in my original e-mail, the recovery behaviour needn't be the
> existing string interpretation, but could just be to treat the value as
> NULL, which would probably be simpler to implement. Personally, I've neve=
r
> actually recovered an E_RECOVERABLE_ERROR, so am not sure what use cases =
we
> should be supporting.


ok, I was assuming that by turning it into E_RECOVERABLE_ERROR you would
still keep the assuming string behavior if there is a custom error handler
which returns true for this error.
I think if we want to remove the assuming string feature, we should handle
it the same way as we handle referencing undefined function call or class
reference(and for consistency the same should be considered for "Undefined
variable", which is also an E_NOTICE atm).
at this point I think I would -1 on removing the assuming this, +0.5 on
turning it into E_DEPRECATED and +1 on turning the "Use of undefined
constant"/"Undefined variable" errors into E_WARNING.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d044287c049c583050db54d44--