Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106830
MIME-Version: 1.0
References: <C228D1E3-C20A-42B8-8006-01E34FFFB5A6@cschneid.com>
In-Reply-To: <C228D1E3-C20A-42B8-8006-01E34FFFB5A6@cschneid.com>
Date: Mon, 2 Sep 2019 16:13:57 +0200
Message-ID: <CAF+90c-SnH0ix0D-2ECgGP3KYmecXVMet39W+ASsVauEoMTFnA@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000022d53c05919296c8"
Subject: Re: [PHP-DEV] Mixed mode methods
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000022d53c05919296c8
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 2, 2019 at 4:03 PM Christian Schneider <cschneid@cschneid.com>
wrote:

> Hi internals,
>
> While some people are trying to make PHP a stricter language I'm also
> interested in making it a more flexible language by allowing to opt-in to
> advanced features for people who want it.
> Please don't shoot this down just because you are not the target audience
> of such a feature ;-)
>
> Toying around with PHP 8 I noticed that it is now impossible to have
> methods which can be called both statically and in an object.
> This proposal brings back mixed mode methods both for extensions and a new
> syntax for user-land functions to explicitly allow it.
>
> Motivation:
> - Make migration of tried-and-tested mixed mode methods easier while
> having to explicitly declare it. So yes, unchanged code gets the new
> stricter semantics but updating code to the new (and from now on
> well-defined) behaviour can be done by simply extending the function
> definition. Having to rewrite such code to two different method names can
> be tedious and error-prone without big benefit.
> - Allowing mixed mode methods as a form of name-overload in cases having
> to have two separate names for static/non-static is a WTF.
> - Reviving things like
>         $elements = DOMDocument::loadXML($html)->childNodes;
>    instead of having to rewrite them to something like
>         ($dom = new DOMDocument)->loadXML($html);
>         $elements = $dom->childNodes;
>    by adding ZEND_ACC_ALLOW_STATIC to the method signature
> (ext/dom/document.c currently still contains code to handle both cases).
>
> A first shot at an implementation was done using the syntax ?static and
> using isset($this) to determine the current mode:
> class A {
>         var $dynamic = 'dynamic';
>         ?static function mixedmodefn() { return isset($this) ?
> $this->dynamic : 'static'; }
> }
> allowing both (new A)->mixedmodefn() and A::mixedmodefn().
>
> The implementation (including a test) can be found at
>
> https://github.com/php/php-src/compare/master...chschneider:optional_static
>
> If people are interested I could create an RFC for this.
>

I'm not in favor of this, but I'll also say that I don't hate it either.

The big problem with what we had before was that any random instance method
could also be used as a static method, which in 99% of the cases was not
intended and would not work. Additionally, the engine had to always account
for this edge-case possibility and perform extra checks that only rarely
did something useful. Your proposal to use an explicit ?static annotation
leaves this as a questionable coding pattern, but I don't see any big
technical problems with it.

Regards,
Nikita

--00000000000022d53c05919296c8--