Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82567
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c86tp4mVtvVjb+z=KExe+infVx0qaQ7S2-mfF=yrym5Vg@mail.gmail.com>
References: <CAF+90c8iVRU8-er+05CJqLb7Pg2viR_-zgwf5jmVyfVWx-+-8Q@mail.gmail.com>
	<54DCD8B7.40700@gmail.com>
	<CAF+90c86tp4mVtvVjb+z=KExe+infVx0qaQ7S2-mfF=yrym5Vg@mail.gmail.com>
Date: Fri, 13 Feb 2015 00:06:46 +0100
Message-ID: <CAH-PCH4Ph4+5mfFKqvmt-ySxfCQng0nWr5vQG6wbA4X3beP1=w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb048768d46ad050eec2cc5
Subject: Re: [PHP-DEV] Remove $this from incompatible context
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bb048768d46ad050eec2cc5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 12, 2015 at 9:20 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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 $th=
is
> >> 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 t=
he
> > 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 an=
d
> E_STRICT in others. I'd like to have a consistent error level in all case=
s,
> 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
>

adding the E_DEPRECATED was only about the assuming $this behavior:
https://wiki.php.net/rfc/incompat_ctx
so if we remove that behavior ($this is set to null) then I'm not sure why
shouldn't we leave the calling non-static method as static as E_STRICT.
are we planning to remove the ability to call non-static methods statically
later on? that would be against the original proposal:
"This proposal is not about removing static calls to instance methods or
instance-like calls to static methods."
and the original plan for removing this behavior was simply to remove/not
assume $this:
"Even though I think an error at call site would be the most useful to the
user, the most sensible option is to just have $this =3D=3D=3D null inside =
the
callee, like when you do"

I think the best course of action would be going with the original plan,
null-ing out $this and keeping the calling a non static method statically
as an E_STRICT.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bb048768d46ad050eec2cc5--