Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82553
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54DCD8B7.40700@gmail.com>
References: <CAF+90c8iVRU8-er+05CJqLb7Pg2viR_-zgwf5jmVyfVWx-+-8Q@mail.gmail.com>
	<54DCD8B7.40700@gmail.com>
Date: Thu, 12 Feb 2015 21:20:04 +0100
Message-ID: <CAF+90c86tp4mVtvVjb+z=KExe+infVx0qaQ7S2-mfF=yrym5Vg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c347506f5448050ee9d855
Subject: Re: [PHP-DEV] Remove $this from incompatible context
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c347506f5448050ee9d855
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 12, 2015 at 5:45 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Nikita Popov wrote on 12/02/2015 14:24:
>
>> Hi internals,
>>
>> As part of [1] and [2] we have decided to remove support for doing static
>> calls to instance methods, if this would result in an incompatible $this
>> variable to be used. When applying [3] this change we found that the
>> change
>> as originally intended may be too strict.
>>
>
> [snip]
>
>  The compromise I'd like to implement instead is to only throw a fatal
>> error
>> if $this is actually used in the called method and otherwise throw a
>> deprecation warning. Calls from instance methods, static methods and
>> functions will all be handled the same.
>>
>
> [snip]
>
> I'm definitely in favour of this over completely forbidding such calls.
>
> The only thing I'd question is the use of E_DEPRECATED when the static
> call doesn't use $this. Is there actually any intent to change the
> behaviour in a future version? What is the advantage to doing so? It
> strikes me as rather like the case of "var" for properties, which had the
> deprecation notice removed.
>
> I think it would make more sense to raise an E_STRICT, since the main
> purpose seems to be to discourage users making such calls.
>

The reason is that previously it was using E_DEPRECATED in some places and
E_STRICT in others. I'd like to have a consistent error level in all cases,
so using E_DEPRECATED everywhere (I am not willing to downgrade existing
deprecations to strict warnings).

And yes, I'm pretty sure there is intent to remove this completely in the
future - this is just another leftover from PHP 4. The approach outlined
here only avoids dropping support in PHP 7 already (which the original
patch did for all practical purposes).

Nikita

--001a11c347506f5448050ee9d855--