Re: [VOTE] Interface Default Methods
| From: | Brent Roose via internals | Date: | Thu, 13 Jul 2023 11:46:16 +0000 |
| Subject: | Re: [VOTE] Interface Default Methods | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120802@lists.php.net to get a copy of this message | ||
I want to pitch in, agreeing with Larry's message here.
- There are multiple real life use cases where the combo trait/interface could be replaced by
interface default methods
- Several modern language apply the technique in one form or another, so it's already proven to
be valuable
- There are a multitude of userland devs who'd benefit from this feature
- The only argument I've heard against this RFC is "it goes against my definition of what
an interface should be". I was also thought that same definition, and I also had to unlearn it.
Just like I had to unlearn the "only one return per method rule" we were taught in college
Brent
> On 12 Jul 2023, at 20:17, Larry Garfield <larry@garfieldtech.com> wrote:
>
> On Wed, Jul 12, 2023, at 4:00 AM, G. P. B. wrote:
>> On Mon, 3 Jul 2023 at 01:11, Levi Morrison <morrison.levi@gmail.com> wrote:
>>
>>> Chatter on the [Interface Default Methods RFC][1] has been quiet for
>>> the past 6 days, and the feature freeze deadline is fast approaching
>>> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
>>> as usual.
>>>
>>> Thanks to everyone who discussed weaknesses in the RFC during the
>>> discussion phase.
>>>
>>> [1]: https://wiki.php.net/rfc/interface-default-methodsóRgj
>>> oÀú9
»À™5
>>>
>>
>> Although I like the idea, I think the main reason for the pushback is how
>> close this is being voted on before feature freeze when the RFC +
>> implementation was updated very recently before.
>> And personally I think, considering this, I would also delay implementing
>> this.
>> We have at least 2 other major RFCs that are being pushed back (Property
>> Hooks and Function autoloading) due to time constraints.
>>
>> Maybe it's time for a more meta discussion about the absurdly long release
>> process PHP has of releasing many intermediate versions that seem to get no
>> testing from userland.
>>
>> For everyone against this feature, I would urge you to understand the
>> distinction between "type classes" and Java-like "interfaces" (which is
>> effectively what PHP interfaces are).
>> A good article is the following one:
>>
>> https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/
>>
>> I also find it baffling the lack of understanding around this feature.
>> Generic programming exists, and it operates on a level where a method can
>> have a "concrete" default representation and still represent the genericity
>> to its fullest.
>> Examples have already been given, such as the Comparable, Equatable, or
>> Iterator type classes.
>> Considering, Haskell, Rust, Scala, and modern PL theory sees no issue with
>> that, I struggle to understand the resistance here.
>
> If I could play armchair shrink for a moment, I suspect a lot of people come from a background
> where "interface is just the behavior definition, not implementation" was drilled into
> them. Which... is the case in older Java when most of us went through school using older Java. So
> it's natural to think that is just a rule of how languages work, and so default methods in
> interfaces is just some weird nonsense from people who don't understand language theory because
> you didn't learn it in school.
>
> At least, I know that description applies to me, so I'm assuming it applies to at least
> some other folks around here. :-)
>
> Realizing "oh, wait, I was wrong about the theory of how things work" is
> uncomfortable, and hard for a lot of people. I was initially luke-warm on it for that reason. But
> seeing how many languages have adopted some form of default methods and lived to tell the tale is
> convincing for me that it actually is a viable "build up a class from separate pieces without
> having to manually write 50 proxy methods" solution. There may be smaller issues with it that
> need to be ironed out (enforcing methods being defined, it working better with interface properties,
> etc.), but the core idea seems to be sound.
>
> It's taken me a while to get used to going through that "oh wait, I was wrong"
> process, so at this point it's not an ego-hit. But that's not a process everyone has gone
> through.
>
> In short, I suspect at least much of the pushback is "that is weird and not normal,
> according to the normal I first learned, so it must be a bad idea," and people just stop there.
>
> (If you voted no and the above description doesn't apply to you, please do explain what
> your alternate reasoning is, because RFC authors desperately need more feedback than we get right
> now.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php