Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81310
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54C90367.5010903@gmail.com>
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>
Date: Wed, 28 Jan 2015 17:42:32 +0100
Message-ID: <CAH-PCH5D6wFTrAA7KoZrJ+mov7J13Eo9rv+LLLRG3F=ZpA4F7w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e010d849edc3ab5050db90eb7
Subject: Re: [PHP-DEV] Proposal: Raise severity of undefined constants
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e010d849edc3ab5050db90eb7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 28, 2015 at 4:42 PM, Rowan Collins <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.


>
> There are actually two parts to the message: that you used an undefined
> constant, and that PHP interpreted this as you wanting a string. If you
> really intended a string, then "deprecated" is relevant; but if you
> intended a keyword or constant, then there is nothing to deprecate, it's
> just an error.
>

yeah, the problem is that we can't tell, what was the intention from the
author, so while I can see how this behavior can cause huge WTF moments for
our users (http://3v4l.org/QW8qV), but there are still a bunch of code out
there relying on it.
having a php version where it is E_DEPRECATED allows people to upgrade to
that version, log the deprecated messages and fix their code.
(ofc. you can also try to detect this specific usage with static analysis,
but that would still miss dynamic usages like eval).


>
> 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 behaviou=
r
> will change in a future version


I don't like mixing the deprecation notice in the string but maybe it's
just me.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e010d849edc3ab5050db90eb7--