Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114141
MIME-Version: 1.0
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>
In-Reply-To: <A631B43E-22B4-490A-8C6F-8BFA0FB30B23@cschneid.com>
Date: Sun, 25 Apr 2021 00:39:47 +0100
Message-ID: <CA+p1FaY7Je3wfMCwCHCKAZEwPQzcRXwdunC=1df98898xqKV-g@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001b079d05c0c06eac"
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: davidgebler@gmail.com (David Gebler)

--0000000000001b079d05c0c06eac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't love this idea, I'm not very fond of the final keyword, either;
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.

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. 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.

On Sat, Apr 24, 2021 at 9:01 PM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 24.04.2021 um 21:51 schrieb Marco Pivetta <ocramius@gmail.com>:
> > On Sat, Apr 24, 2021, 21:44 Olle H=C3=A4rstedt <olleharstedt@gmail.com
> <mailto:olleharstedt@gmail.com>> wrote:
> >
> >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati <azjezz@void.tn>:
> >>>> Doesn't this violate the principle: It should be possible to add new
> >>>> features without touching old code?
> >>>
> >>> This depends on which syntax is picked, both `for` and attribute synt=
ax
> >> will
> >>> be completely BC.
> >>
> >> I'm not talking about BC, but the maintainability of the new feature
> >> itself. For the shape example, you'd need to edit the original file
> >> for each new shape you add, which is detrimental for maintainability
> >> and scalability. So what's a good use-case?
>
> I'm with Olle here: This sounds like an anti-pattern to me.
> The example could not be worse: Why should I not be allowed to add a
> hexagon shape?
>
> > The main use-case of sealed types is being able to declare total
> functions
> > around them.
>
> Could you elaborate on what's the real-world use-case for your main
> use-case?
> This sounds like another case of a feature based in (math) theory which
> leads to artificially locked down code.
>
> - Chris
>
>

--0000000000001b079d05c0c06eac--