Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118407
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-811-gb808317eab-fm-20220801.001-gb808317e
Mime-Version: 1.0
Message-ID: <1f37ea30-249c-46fd-b99d-9f2097ed86b2@www.fastmail.com>
In-Reply-To: 
 <CADK1yXLVqD2hfuj66VZAgfhPXnZUOdB-nEy82H=YA+UKUyK-Kw@mail.gmail.com>
References: 
 <CABigaAWAMfjTh9FBhu-SQRfu9_pgqt5pp7uj4kmNg0QmXbnS-Q@mail.gmail.com>
 <62f3da67.810a0220.ed5e8.1b2cSMTPIN_ADDED_MISSING@mx.google.com>
 <CALKiJKqjLqwyC+5zyfo=NaeZpyGRv8K4_dzQ7fRtH_48j9Hciw@mail.gmail.com>
 <CABigaAUNweFCnDryt8yZ4m2Cn3Rn8HACNVxvj+RvxrPFets5vw@mail.gmail.com>
 <17C7EF67-298D-40E8-A872-5A9D78A7EEDA@gmail.com>
 <CADK1yXLVqD2hfuj66VZAgfhPXnZUOdB-nEy82H=YA+UKUyK-Kw@mail.gmail.com>
Date: Wed, 10 Aug 2022 19:10:40 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [Concept] Extension methods
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Aug 10, 2022, at 5:23 PM, Deleu wrote:
> On Wed, Aug 10, 2022, 11:30 PM Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
>>
>> To be honest, I put them in that order more for "purity" reasons: if they
>> come before __call, they can change the existing behaviour of the class, by
>> defining an extension method with the same name as a "virtual" method
>> implemented with __call. That then becomes a very different feature.
>>
>
> I would argue in favor of extension having precedence over __call because
> 1) classes with __call wouldn't be able to be `extended` and 2) extensions
> could actually "fix" the ~ab~use of some use of __call. I suppose this
> would allow me to write an Extension that mimics the exact behavior of
> __call and actually avoid __call from being hit while still keeping the
> same behavior of the class.

Possibly very dumb idea, but I'll throw it out anyway:

Would it be OK if extension methods came *before* normal methods?  Would that allow a compile time translation of this:

use extension Foo:bar;

$collection->bar($b);

to this:

Foo::bar($collection, $b);

Since the extension would only have public access anyway (modulo messing around with rebinding and reflection, of course), it's logically equivalent to just a static method like that.  That could allow the existing autoload logic to work (if extensions compile into just classes), and no runtime overhead because it's "Just" a static method call; if it's missing, oh well, it just fails like a static method call.

A side effect of that is indeed that you could override an object's method externally, in effect, at the loss of internal access.  I... could probably make a solid argument for that being very good or very bad, depending on my mood.

(I'm at the moment lukewarm on the idea overall, and I still believe pipes are the superior solution, but if we do it then it should be done well.)

--Larry Garfield