Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <54C8BE99.8070109@gmail.com>
Date: Wed, 28 Jan 2015 10:48:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <54C80F4F.7020905@gmail.com>	<011d01d03ab7$dd725c30$98571490$@tekwire.net> <CAH-PCH7UstXaV67S141fNxpTMyEwChZs5u9NaY3x53JBgqk3WQ@mail.gmail.com>
In-Reply-To: <CAH-PCH7UstXaV67S141fNxpTMyEwChZs5u9NaY3x53JBgqk3WQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070206010401020308060105"
Subject: Re: [PHP-DEV] Proposal: Raise severity of undefined constants
From: rowan.collins@gmail.com (Rowan Collins)

--------------070206010401020308060105
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Ferenc Kovacs wrote on 28/01/2015 07:20:
>
>
> 2015.01.28. 6:04 ezt írta ("François Laupretre" <francois@tekwire.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 constant
> > > 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 
> either 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 gain 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.

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 
had 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 never actually recovered an E_RECOVERABLE_ERROR, so am 
not sure what use cases we should be supporting.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------070206010401020308060105--