Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81312
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
Message-ID: <54C91C28.5020000@gmail.com>
Date: Wed, 28 Jan 2015 17:28:08 +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>	<54C8BE99.8070109@gmail.com>	<CAH-PCH7fDygM17XVPTeiEfccsQX0oH0Ui5C_mYN=_9osvzQGVw@mail.gmail.com>	<54C90367.5010903@gmail.com> <CAH-PCH5D6wFTrAA7KoZrJ+mov7J13Eo9rv+LLLRG3F=ZpA4F7w@mail.gmail.com>
In-Reply-To: <CAH-PCH5D6wFTrAA7KoZrJ+mov7J13Eo9rv+LLLRG3F=ZpA4F7w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------060400010209020707020101"
Subject: Re: [PHP-DEV] Proposal: Raise severity of undefined constants
From: rowan.collins@gmail.com (Rowan Collins)

--------------060400010209020707020101
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Ferenc Kovacs wrote on 28/01/2015 16:42:
>
>
> On Wed, Jan 28, 2015 at 4:42 PM, Rowan Collins 
> <rowan.collins@gmail.com <mailto:rowan.collins@gmail.com>> wrote:
>
>     Ferenc Kovacs wrote on 28/01/2015 12:13:
>
>
>             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.
>
>
>     I see absolutely no advantage in changing this into E_DEPRECATED,
>     as it's even more likely to be hidden or ignored than E_NOTICE.
>
>
> removing a feature (which is present in the language since 4.0, 
> probably even previously) without marking it deprecated first would be 
> a rude move imo.
> so if we want to remove it, I can't see any other way.

The only documentation I can find mentioning it explicitly discourages 
is it, so I don't think it's a huge stretch to say that it's already 
deprecated, but if we feel that's not enough, we may not want to jump 
straight to fatal. However, I don't think changing to E_DEPRECATED is 
the only, or best, way of warning people of future removal.


> (ofc. you can also try to detect this specific usage with static 
> analysis, but that would still miss dynamic usages like eval).

Actually, I was going to mention that it's quite hard to spot with 
static analysis, because like classes and functions, you have to chase 
includes to know what's defined. Unless you look for bare words which 
aren't all caps, I suppose.


>     If we want to keep the string fallback for now, how about we raise
>     the severity to E_WARNING, and change the message to mention
>     deprecation?
>     e.g.
>     Warning: Use of undefined constant foo - assumed 'foo', but this
>     behaviour will change in a future version
>
>
> I don't like mixing the deprecation notice in the string but maybe 
> it's just me.

I know it's unusual, but I think really there are two messages we're 
expressing: "Warning: Undefined constant" and "Deprecated: Using 
unquoted string". Unless we issue both at once (which seems 
unnecessarily confusing), I think the higher of the two severities 
should be used. But maybe that's just me, I'll see what others think.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------060400010209020707020101--