Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114149
Message-ID: <0BF84585-DDC3-4B25-BFD2-D8B916D135EE@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FEC780C2-16CC-4D70-BA36-64CB35B93988"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Sun, 25 Apr 2021 11:36:24 -0400
In-Reply-To: <CA+p1FaY7Je3wfMCwCHCKAZEwPQzcRXwdunC=1df98898xqKV-g@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: David Gebler <davidgebler@gmail.com>
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>
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_FEC780C2-16CC-4D70-BA36-64CB35B93988
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Apr 24, 2021, at 7:39 PM, David Gebler <davidgebler@gmail.com> =
wrote:
>=20
> I don't love this idea, I'm not very fond of the final keyword, =
either;

I'll start by saying the final keyword caused me a tremendous amount of =
heartache because it was used on a class in a framework that I badly, =
badly needed to extend.

But even so, I recognize why they used it, and I still don't have a =
great argument for how they could address the reasons they used it some =
other way.

> I've always believed annotations (or attributes in PHP these days) are =
a
> better of way of indicating you, as an author of a class, did not =
write it
> with inheritability in mind or intended than restricting language =
features
> through syntactic constructs.
>=20
> The RFC says "when you have a class in your code base that shares some
> implementation detail between 2 or more other objects, your only =
protection
> against others making use of this class is to add `@internal` =
annotation,
> which doesn't offer any runtime guarantee that no one is extending =
this
> object", to which I ask - why do you need this guarantee? What does it
> qualitatively add? If I make a judgement that I want to extend your =
class
> or implement your interface, I can just delete the sealed keyword from =
your
> code and carry on. So it doesn't actually offer any guarantee at all =
that
> I'm not extending the type.

Actually, it does offer such a guarantee.  It guarantees if you are =
using a non-forked version of the original developer's (OD's) library or =
framework then that class won't be extended. When someone pulls the =
original non-forked version from its source repository =E2=80=94 such as =
when using Composer =E2=80=94 then that code will be (effectively) =
guaranteed not to be extended.

OTOH, if you do delete the sealed (or final) keyword you have then =
forked the code, in a defacto manner if not a literal one. If you use a =
forked version of the code, you now own the maintenance of that code and =
any bugs that are generated by your forked changes in using code. The =
original developer has no moral, ethical or even contractual obligation =
to care about the breakage you cause.

Hypothetical example:  You fork the code, remove sealed/final, then =
subclass the code and add a method, let's call it ToString(). And you =
write your application to use ToString(). Now the OD releases a new =
minor version and they also add a ToString() method. Applications using =
your fork probably cannot use the new version of the OD's library =
because when the library calls ToString() your version is called. So you =
have to update your application to use the new version of the library =
and once again remove sealed/final.

AND, if your code is instead another add-on library, now users of your =
add-on library will also have to fix their code too.  Which could =
potentially be a large number of users if your add-on is successful.

So not using final or sealed can result in some really hairy and =
possibly impossible to fully resolve backward compatibility concerns for =
developers who publish libraries and/or frameworks.

> The best it can achieve is to indicate your
> intentions, which I believe can be adequately done today through an
> attribute, no addition to the language needed.

Still, I concur with your concerns.  Developers too often implement =
final classes in libraries and frameworks without fully addressing all =
the use-cases and/or adding enough extensibility points because it makes =
their lives easier.  Because of that final =E2=80=94 and sealed, if =
added =E2=80=94 can make the life of an application developer a living =
hell.

So what's the answer?  I don't know that I have the ultimate answer, but =
I would be a lot more comfortable with adding features to PHP such as =
ones like sealed that restrict the "O" in S.O.L.I.D.[0] if PHP were to =
offer the following three (3) things, all of which can be found in Go, =
and I am sure other languages:

1. Class embedding[1] =E2=80=94 Allows one class to embed another and =
immediately have access to all its properties and methods, and also to =
be able to extract an instance of that embedded class.  It is called =
"Type embedding" in Go.

2.Type definitions[2] =E2=80=94 A typedef would allow developers to =
define constrained versions of existing types, such as `FiveStarRating` =
which could only contain 1, 2, 3, 4 or 5, or types that identify a =
signature, for example as `ConvertToString` which could require a =
closure that implements `func(mixed):string`. In Go you can compose =
other types to create new types, but I'm not sure if those other type of =
types could apply to PHP, at least as it currently exists, and =
especially because it is not a compiled language.

3. Structural typing[3] =E2=80=94 Basically interfaces that can be =
implemented implicitly rather than explicitly.  For example, if I wanted =
to implement a Stringable interface that requires a ToString():string =
method then structural typing would allow me to implement that interface =
simply by adding a ToString() method instead of requiring me to also add =
"implements Stringable" to the class definition.=20

Those three features are all killer language features and would make =
great additions to PHP.  IMO, of course.

#fwiw

-Mike

[0] https://stackify.com/solid-design-open-closed-principle/
[1] https://travix.io/type-embedding-in-go-ba40dd4264df
[2] https://go101.org/article/type-system-overview.html
[3] =
https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/ =
<https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/>=

--Apple-Mail=_FEC780C2-16CC-4D70-BA36-64CB35B93988--