Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114161
Return-Path: <mike@newclarity.net>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 46684 invoked from network); 25 Apr 2021 19:48:19 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 25 Apr 2021 19:48:19 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id BC2941804DB
	for <internals@lists.php.net>; Sun, 25 Apr 2021 12:52:10 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,
	SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2
X-Spam-Virus: No
X-Envelope-From: <mike@newclarity.net>
Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Sun, 25 Apr 2021 12:52:10 -0700 (PDT)
Received: by mail-qt1-f178.google.com with SMTP id d6so21931260qtx.13
        for <internals@lists.php.net>; Sun, 25 Apr 2021 12:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=newclarity-net.20150623.gappssmtp.com; s=20150623;
        h=mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=QaqfmnDKoPu84oGfRr0KXM/Kmk21eQPLGbI+J7paquM=;
        b=aY1Gs5JzHNGgzdUb3Zjy8w9vcZSWb3eRCJGGJEQZjmMXk/SR3pdeAh2Ub4aAv3LQvO
         1/SRXUWT7+I4LINX160nTIDPnqdQiBQJyCpHhBBIMISDQyM83ordUqsYczUtBu3SvMfy
         +MuWSrwVh1qJ6k1szjruj6WQMW7bIqK0CWyB/XoNETlE8WsqFgjRWDAUMAkcCJmGyifY
         Diw/nIlxWU33hpiAEndKJ3cZBt2Qnb/ikhQkEDwpWmeA6IDlbz90VoGwm6VLfxhgk/4x
         qqrRxBRt4bmzAcAjhKnMHe1lgtuKwPzDmnEFoH1pJPX+uiql98m0npeiDxX1mrdcT6Lc
         HDzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=QaqfmnDKoPu84oGfRr0KXM/Kmk21eQPLGbI+J7paquM=;
        b=BS1uOOr0ryXLp4VbEgxQBQ/+IcGRoA4k5C5taPsgGokvJ+CmSrNr0W05a7u98MSNnR
         zkZmretDlfcrtH7oj06ViVujS12Dw9BrjqTYyQPbJPSa0JhPeOqAY6FPDQUb0JbHfJE2
         ROYVCkhnHZTbZXOpEnVT7pXT9LoHjHZ9WxCGcO7s3F1pQHmqZvw7HMVMEnFKBLgzFlYg
         Mgod5DIASjAKtxKsCBE9tXU2Vg29HOOnJR4A8N88Pp/xXeimDHgwrKICFFVNSscPtr3+
         7/84z8rbEWqHvoPX/ucBog3cOyuPv47euNsdurJQQZNWtqPHWDANFznye5rsP8ikX0Vs
         1osA==
X-Gm-Message-State: AOAM530/5CLt4UkW4mU+5eQN4rgwpC1Je3jNdFI3u/0t56K3ZLFUmgIZ
	AzB+VNsCCvoKfbZ+p0But+rlyQ==
X-Google-Smtp-Source: ABdhPJywoZZPsifmUzbPEbClBrUjFSEMeJSRITyJHoN5k4UF1UnacR91sqUE84DQ+v1P7CnjNMhuoA==
X-Received: by 2002:a05:622a:18b:: with SMTP id s11mr14027283qtw.26.1619380327994;
        Sun, 25 Apr 2021 12:52:07 -0700 (PDT)
Received: from [192.168.1.10] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8])
        by smtp.gmail.com with ESMTPSA id z17sm9059651qtf.10.2021.04.25.12.52.07
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 25 Apr 2021 12:52:07 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
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