Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114207
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>
 <CAJpLVh3C63FTUzWusVOp5JOGpuKbOYi0WovYvNFv20npNJFh3g@mail.gmail.com>
 <b4276d92-4856-4222-8c34-55b1422030c5@www.fastmail.com> <EA268E52-2954-40DE-B3CC-D447A4983887@cschneid.com>
 <CAC5V6gghaZv=MCQz+FWNDAMUj2KorjvL_tNO+DNAPT0ioycpSA@mail.gmail.com>
 <CA+p1FabuUDUzMkEhwyy0BJVd71N=6ubn5pEJNh8VkE8D9rJhow@mail.gmail.com> <722ed544-69e3-3be4-f828-185914617228@processus.org>
In-Reply-To: <722ed544-69e3-3be4-f828-185914617228@processus.org>
Date: Tue, 27 Apr 2021 18:51:25 +0100
Message-ID: <CA+p1FaZjWc+cMrfWkGP5LCmv6YOKF3h7dY_yYXxCmfUpRfp4fw@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: Guilliam Xavier <guilliam.xavier@gmail.com>, Christian Schneider <cschneid@cschneid.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e6d40105c0f7e990"
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: davidgebler@gmail.com (David Gebler)

--000000000000e6d40105c0f7e990
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 27, 2021 at 6:19 PM Pierre <pierre-php@processus.org> wrote:

> Le 27/04/2021 =C3=A0 18:46, David Gebler a =C3=A9crit :
> > What's being proposed in the RFC is a functional change to the language
> > whereby attempting to extend a class designated as sealed to a
> > non-specified child results in a fatal error.
>
> It's not a functional change to the language, well, it is a new feature,
> but it's actually not changing any paradigm in the language or the
> engine. People will continue to write the same code, and people that
> want to use it for some library or customer project internal purpose may
> use it.
>

If you introduce it, people will use it and the people who use their code
will (no pun intended) inherit it. So the idea that no one is obligated to
use this pattern if they don't want to is at least de facto untrue.


>
> > Now that is not a benefit in itself, it is merely a description of the
> > proposed change. My question is who or what benefits from this change?
> And
> > I look at this way:
> >
> > 1. The language engine doesn't benefit, since unlike some compiled
> > languages, there is no indication here it will result in improved opcod=
e
> > sequences.
> >
> > 2. The author of code doesn't benefit, to any extent greater than they
> > would by using an attribute or other metadata to indicate their
> intentions,
> > because if someone else comes along, installs their library and creates
> > problems for themselves by extending some concrete type in a manner whi=
ch
> > was not intended, the author's obligation to them is zero. If improperl=
y
> > inheriting or otherwise misusing code creates a problem for a consumer,
> > it's the consumer's mess to sort out.
>
> I think that the debate "but if your seal your classes I won't be to
> extend it" is overrated: it's not the language to chose whether or not
> the library/software author can seal its classes or not, it's up the
> library/software author to do its own choice.


Agree, which is precisely why I challenge there is any need for it to be
enforced in the language with a fatal error.


> And in that regard, having
> "sealed" classes in the language is actually bringing that possibility
> to the library author, so it's more liberty.
>
> By design, by convention, in any of a company or an open source software
> community, it can be legit to explicitly hard-seal stuff, for blocking
> users when they are doing it wrong, if for example by attempting to
> inherit they will break other existing piece code, for example. There's
> many scenarios where it's legit to seal classes, and it can be a good
> practice also (depend on your practices I guess).
>
> But if sealing means "you who want to change a behavior, you need to fix
> other things deep in the code before being able to do that" then it's
> good (and it's one of the use cases of sealing).
>
> So each time someone use the "but we won't be able to legitimately
> extend your class" he's basically saying that people that do put very
> thorough and strict conventions in their own code are wrong by nature
> and don't understand what is good. It's almost an insult - please don't
> misunderstand what I say,


I entirely understand and appreciate your view here, but it's no more
insulting than to say to your users "You are wrong by nature; I know your
use-case better than you do (without even seeing it or having knowledge of
it) and there is no legitimate reason for you to ever extend my class"


> I don't think at any moment that any of the
> people here really meant that, but it it's fundamentally what this
> argument does: it says that some conventions are by nature bad and the
> language should enforce people not to write code like this.

I think the language should not enforce any practice, convention or code
> style, it must remain neutral considering people's whereabouts,
> workflows or practices. If one's want to seal his or her class, let him
> or her do it.
>

Some conventions may or may not be bad by nature but that's not the
argument I'm making, at all. The language enforcing one person's
preferences over another's is exactly what you are advocating and I am
cautioning against.


>
> I think this point/argument should be banned from this discussion.


Given the behaviour we're talking about is literally the change proposed in
the RFC, I find this a very strange take.


>
> Sealed classes are good under some conditions, maybe bad under others,
> that's not the point, it's not about discussing each developer's,
> community's or company's own conventions, but about is it OK technically
> to add this feature to the language, and will it be or not a maintenance
> burden, and finally will it actually break millions of lines of existing
> code.
>
> I'm inclined to say yes, it is good to add this feature, and I'm
> skeptical about the fact that it would break existing code (except for
> people that named their classes "Permits"), there's many use cases I
> wish I had it in the past. I can live with it, but sometime, it could be
> the right tool.
>
> Regards,
>
> --
>
> Pierre
>
>

--000000000000e6d40105c0f7e990--