Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114161
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <CA+p1FaboqA1sBe2h9GOM9m5oAUmnYWnhZ-uocdLHEYhm3nJnww@mail.gmail.com>
Date: Sun, 25 Apr 2021 15:52:07 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C2036139-8269-46BA-9F3A-FB7A27555939@newclarity.net>
References: <V7C5-r6tzKmxjhPnvy9gtfdMtxkj0z_PJphaehaqcPsOLX0pEKtGU4A8EuSKyS-cbZl5HPVA2ejXCuXXOfOksH9VACGOKT3awRsr9aSNIg8=@protonmail.com>
 <5b9f1500-615a-48f1-815f-1d48b327ef90@processus.org>
 <CAJpLVh2UybGgAqhfAGQ=kKQ-qvmG68HWKaUJXOwPv7DgEbAdKw@mail.gmail.com>
 <179049b1475.11134368b213512.254739612773841999@void.tn>
 <CAJpLVh0pz_WopKza=XXqPrvS4bQZhWom1FQ6QLW-fbC-8JHkrA@mail.gmail.com>
 <CADyq6sLtgNkyM-qQcwRY8mMOxnkrz_9qeG6XK2uDBqsh=smMtg@mail.gmail.com>
 <A631B43E-22B4-490A-8C6F-8BFA0FB30B23@cschneid.com>
 <CA+p1FaY7Je3wfMCwCHCKAZEwPQzcRXwdunC=1df98898xqKV-g@mail.gmail.com>
 <0BF84585-DDC3-4B25-BFD2-D8B916D135EE@newclarity.net>
 <CA+p1FaboqA1sBe2h9GOM9m5oAUmnYWnhZ-uocdLHEYhm3nJnww@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: mike@newclarity.net (Mike Schinkel)

> On Apr 25, 2021, at 1:52 PM, David Gebler <davidgebler@gmail.com> =
wrote:
>=20
> Still, all these problems are solved to the same degree if you add a
> #[Sealed] attribute to a class which has no functional impact. You =
have
> sufficiently indicated to any user that extending this class is not a
> designed feature and may cause backwards-incompatible breaks with =
future
> releases - in a way that both a programmer and IDE can reason about, =
which
> in PHP's context is what matters. Attributes arguably even have a =
greater
> qualitative advantage that they can be applied right down as far as
> individual method parameters.

In my experience, if a developer needs access to a feature that is =
easily available via the use of a method that is merely documented as =
internal-use only, the developer will use it rather anyway than spend a =
lot more time trying to work around what that method makes easily =
available.  Especially if that documented internal-use only is about not =
subclassing.

And if many other developers do that, the original developer will still =
have the same problem as if they didn't document it as internal-use =
only.

But I do acknowledge your experience might be different.  FWIW.

> In Java the idea of final and sealed classes makes more sense, since =
we
> actually to some extent need the compiler to be able to reason about =
these
> types and can gain optimization and code generation benefits from its =
being
> able to do so. PHP's concept of typing and implementation of type =
checking
> as an interpreted language is completely different.
>=20
> I wonder, if final and sealed as language constructs really offer the
> guarantees about intent and safety their advocates say they do, why =
are
> they not the default? Why can no one point me to a language where I =
have to
> write something like
>=20
> extendable class Foo permits all { .... }
>=20
> (and there are people who would be in favour of making inheritability =
this
> explicit, but I'm not one of them)

Well, I can't point you to a language that works that way because I =
don't know more than a handful of languages in depth =E2=80=94 although =
there may be one =E2=80=94 but I can point you to a language that does =
not even allow you to subclass: Go. =20

The Go designers wanted to get away from the fragile base class problem =
so they provided embedding instead:

=
https://medium.com/@simplyianm/why-gos-structs-are-superior-to-class-based=
-inheritance-b661ba897c67
=20
I program more in Go now than in PHP, and I can confirm that its =
approach works brilliantly. Better IMO than what PHP currently offers in =
that respect.

> It's one thing as an author of code to say "I only intended and =
support
> this finite set of use-cases", it's quite another to say "and you =
should be
> impeded from proceeding with any legitimate use-case I didn't imagine =
or
> foresee"

I do respect that as a user of other developer's code you might view it =
that way. =20

But then I also can respect the library or framework developer who =
chooses to make their own job less difficult by (wanting to) mark a =
class to be sealed.

You claim "it's quite another thing to say" but I don't think a =
developer of library or framework code should be required to offer =
features to their users they do not want to offer.  It is the =
developer's prerogative; if they want to be able to mark their classes =
as sealed they should be empowered to do so. IMHO, anyway.

> In practice, the only thing I've ever seen this achieve is to create
> difficulties, while the claimed benefits can be adequately (and =
better)
> achieved through existing patterns like annotations, interfaces and =
DI.

I would argue that maybe the reason you have only seen it create =
difficulties is because of your own perspective and experiences that =
are, by definition, anecdotal and thus limited.

OTOH Fabien Potencier and/or Taylor Otwell might have a different =
experiences and thus a different perspective on what those benefits are =
(but I am admittedly just hypothesizing here.)

-Mike