Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129135
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 07 Nov 2025 12:54:37 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <611bb7bf-6cb1-4fa7-bab0-9d3bdc355989@app.fastmail.com>
In-Reply-To: 
 <CAOHeFxfjsfdqb1uFV-rb4VwAAW7M4vuu+Qo-QzdRYNyJsFxcjg@mail.gmail.com>
References: 
 <CAOHeFxdVqM-q14h9BHZ5628o-sQZ-wuDv9r+BrE8Z5=h0i+ToA@mail.gmail.com>
 <83BA9524-6095-4C8B-8F82-B2F344C4D062@zort.net>
 <CAOHeFxfjsfdqb1uFV-rb4VwAAW7M4vuu+Qo-QzdRYNyJsFxcjg@mail.gmail.com>
Subject: Re: [PHP-DEV] Pre-RFC proposal: opt-in implicit interfaces / structural typing
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Nov 7, 2025, at 12:23 PM, Spencer Malone wrote:
> The extension idea is interesting! I hadn't thought of that. 
> Autoloading might be a PITA with that, I'm trying to think of how you 
> would manage that?
>
> On the subject of "mistaken typing" or implicit interfaces being met by 
> classes that don't actually do the desired behavior, I think you're 
> right it's a risk, my counterargument is typescript and golang both 
> have implicit interfaces in some form (well typescript calls them 
> structural typing), but I don't think in either language I've ever 
> really run into a case where that risk becomes a reality. I'm hesitant 
> to declare this because I'm not sure this is the best way to frame this 
> from a PR perspective, but in many respects this proposal is viewable 
> as a syntax shortcut to duck typing, which is already pretty common 
> across PHP. While there are definitely drawbacks to duck typing, it's 
> still a very useful tool IMO (and becomes very cumbersome if you need 
> to duck type a larger set of functions).

(Please do not top post.)

Languages with implicit interfaces like Go also go (no pun intended) "all in" on it.  All methods on an object are defined externally, possibly not even in the same file.  The whole standard lib was built on that model from the ground up.  That's not the case in PHP.  

I've been pondering extension functions for some time, and have kicked the idea around with John before.  (I would do it as functions, a la Kotlin, not as a secondary class, like Rust.)  Autoloading and efficiently determining that you need to call an extension are the key stumbling blocks (though my stance on autoloading at this point is "we've got opcache enabled 100% of the time, we have things like FrankenPHP, just front-load the file and move on with your life).  

I could see implicit interfaces working in conjunction with extension functions, if we can figure those out.  I'm not sure if they offer much value without them, given the state of PHP.  It would basically mean you have to opt-out of a type rather than opt-in, as now.  That could get... weird.

--Larry Garfield