Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114188
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C9772446-F08B-4D7E-B4CF-6F1D83986F11"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 26 Apr 2021 14:59:38 +0200
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>
 <CAJpLVh3C63FTUzWusVOp5JOGpuKbOYi0WovYvNFv20npNJFh3g@mail.gmail.com>
 <b4276d92-4856-4222-8c34-55b1422030c5@www.fastmail.com>
 <EA268E52-2954-40DE-B3CC-D447A4983887@cschneid.com>
 <CAPyj-LCHWDBNTwVWx8nKVJ3ED8psFO+BtzD1G=xRpDKQsFG2fg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
In-Reply-To: <CAPyj-LCHWDBNTwVWx8nKVJ3ED8psFO+BtzD1G=xRpDKQsFG2fg@mail.gmail.com>
Message-ID: <D664536B-AEFB-4E27-9331-24BB77B3CB85@cschneid.com>
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: cschneid@cschneid.com (Christian Schneider)

--Apple-Mail=_C9772446-F08B-4D7E-B4CF-6F1D83986F11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 26.04.2021 um 14:18 schrieb Ilija Tovilo <tovilo.ilija@gmail.com>:
> The point of sealed type is to fix the number of subclasses a given
> type can have, which means you can handle a value by type (as that
> list is not finite). Code that handles Optional values could look like
> this:
>=20
> ```
> if ($option instanceof Option\None) {
>    throw new Exception();
> }
>=20
> // We now know the value is a Some
> var_dump($option->value);
> ```

I really hope that's *not* the way people will use the Maybe type....

> If you suddenly provide your own version of None the code above will
> break.

... but no, it wouldn't break, as MyNone extends None, so instanceof =
would still work.

> To most people it's obvious that you can't add new cases to an
> existing enum.

The RFC does not mention data classes (at least not explicitly), it =
talks about sharing common functionality.
So I think you're somewhat moving the goal posts.
If you want to limit Enums only then I would have to reconsider, but we =
were talking about generic classes AFAIK.

> It doesn't sound sensible to add logging to a data
> class. That's something that belongs into a hook or service of some
> kind.

You're again making assumption about what's sensible for the user of a =
library, that's the mind-set I would like to avoid.

> People might also want to use sealed for behavioral classes, the use
> case here is the same as final. Final is not here to make your life
> harder. It's here to make the lives of the library maintainers easier.

First of all: Yes, I'm no fan of final either.
I've encountered enough examples where it *did* make my life harder.
And as a library writer myself I value the user experience higher than =
the library developer work because there are (hopefully) a lot more =
users than developers.

> If they have to reason about every way a method could be overridden,
> every change in the library would become more risky, require more
> thought and more frequent major version updates.

A properly designed API should be simple and stable enough to not need =
this kind of safe-guards.
Overly complicated, cathedral-style frameworks might yearn for it but I =
think it's addressing the symptoms, not the cause (-:C

> This means more work and less features for you, too.


That kind of argument reminds me of people saying that user tracking is =
a good thing because I get to see more relevant advertisement.
You're a good sales-man though, I give you that, but you haven't =
convinced me yet ;-)

- Chris


--Apple-Mail=_C9772446-F08B-4D7E-B4CF-6F1D83986F11--