Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114156
User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b
Mime-Version: 1.0
Message-ID: <d0f6a35d-9954-4dbc-80fc-11767d86ebac@www.fastmail.com>
In-Reply-To: 
 <CA+p1FaboqA1sBe2h9GOM9m5oAUmnYWnhZ-uocdLHEYhm3nJnww@mail.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>
 <0BF84585-DDC3-4B25-BFD2-D8B916D135EE@newclarity.net>
 <CA+p1FaboqA1sBe2h9GOM9m5oAUmnYWnhZ-uocdLHEYhm3nJnww@mail.gmail.com>
Date: Sun, 25 Apr 2021 14:22:07 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: larry@garfieldtech.com ("Larry Garfield")

Stitching together 2 replies to minimize thread noise...

On Sun, Apr 25, 2021, at 11:58 AM, Micha=C5=82 Marcin Brzuchalski wrote:=


> Speaking of Attributes I prefer not to use an Attribute for any partic=
ular
> language feature which expects input arguments to be a valid class or
> interface name for two reasons: first because there is no effective wa=
y to
> restrict input string to be a valid class or interface name and second=
 that
> it'd require passing strings which means in most cases passing class o=
r
> interface name with magic ::class constant read.
>=20
> Cheers,
> Micha=C5=82 Marcin Brzuchalski

That's actually a pretty solid argument against attributes here, honestl=
y.  Consider me convinced, and now in favor of "final class Foo permits =
Bar, Baz". :-)


On Sun, Apr 25, 2021, at 12:52 PM, David Gebler wrote:
> 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 hav=
e
> sufficiently indicated to any user that extending this class is not a
> designed feature and may cause backwards-incompatible breaks with futu=
re
> releases - in a way that both a programmer and IDE can reason about, w=
hich
> in PHP's context is what matters. Attributes arguably even have a grea=
ter
> qualitative advantage that they can be applied right down as far as
> individual method parameters.
>=20
> In Java the idea of final and sealed classes makes more sense, since w=
e
> actually to some extent need the compiler to be able to reason about t=
hese
> 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 chec=
king
> 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 ar=
e
> they not the default? Why can no one point me to a language where I ha=
ve 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)
>=20
> It's one thing as an author of code to say "I only intended and suppor=
t
> this finite set of use-cases", it's quite another to say "and you shou=
ld be
> impeded from proceeding with any legitimate use-case I didn't imagine =
or
> foresee"
>=20
> 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=
.

Part of the challenge here, i think, is that PHP, like most classic OOP =
languages, uses the same syntax for two different things.  One is for pr=
oduct types (an int combined with a string together in a single struct),=
 the other is bound values in closures (aka, methods in service objects)=
.  That's arguably by design in classic OOP, and arguably a design flow =
in classic OOP. :-)

I can think of no reason at all to make a service object's class sealed.=
  For those, yes, you shouldn't forbid custom extension, and frankly I u=
sually discourage the use of private variables, too, for the same reason=
.

For product types that are part of the domain, however, there are defini=
tely use cases where you want a defined finite list of possible variants=
.  The Distance and Maybe examples upthread, for instance.  That's not a=
lways the case, but there are definitely cases for them.

--Larry Garfield