Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120802
Reply-To: Brent Roose <brent.roose@jetbrains.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_11D22753-1C8A-49EE-B8EC-F394D23305B9"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Thu, 13 Jul 2023 13:46:16 +0200
References: <CAFMT4Nq3y+XKUP7aG7F7aht1DdM7dpqxMT-hcS+Nyvc9FaT=+A@mail.gmail.com>
 <CAFPFaMJyE9EWv=8RdC=T0sB1bt6f5CrQikh3s+p6oTo-RbM6BQ@mail.gmail.com>
 <18e1c012-818c-44ee-ba95-c000860ac390@app.fastmail.com>
To: PHP Internals <internals@lists.php.net>
In-Reply-To: <18e1c012-818c-44ee-ba95-c000860ac390@app.fastmail.com>
Message-ID: <F7F0AF7C-42D3-4D48-9613-335C65FBCDA3@jetbrains.com>
Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods
From: internals@lists.php.net ("Brent Roose via internals")

--Apple-Mail=_11D22753-1C8A-49EE-B8EC-F394D23305B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I want to pitch in, agreeing with Larry's message here.=20

- 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:
>=20
> 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:
>>=20
>>> 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.
>>>=20
>>> Thanks to everyone who discussed weaknesses in the RFC during the
>>> discussion phase.
>>>=20
>>>  [1]: https://wiki.php.net/rfc/interface-default-methods
>>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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/
>>=20
>> 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.
>=20
> 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.
>=20
> At least, I know that description applies to me, so I'm assuming it =
applies to at least some other folks around here. :-)
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> (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.)
>=20
> --Larry Garfield
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


--Apple-Mail=_11D22753-1C8A-49EE-B8EC-F394D23305B9--