Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114206
To: David Gebler <davidgebler@gmail.com>,
 Guilliam Xavier <guilliam.xavier@gmail.com>
Cc: Christian Schneider <cschneid@cschneid.com>,
 PHP Internals <internals@lists.php.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>
 <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>
Message-ID: <722ed544-69e3-3be4-f828-185914617228@processus.org>
Date: Tue, 27 Apr 2021 19:19:20 +0200
MIME-Version: 1.0
In-Reply-To: <CA+p1FabuUDUzMkEhwyy0BJVd71N=6ubn5pEJNh8VkE8D9rJhow@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: pierre-php@processus.org (Pierre)

Le 27/04/2021 à 18:46, David Gebler a écrit :
> 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.

> 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 opcode
> 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 which
> was not intended, the author's obligation to them is zero. If improperly
> 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. 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 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.

I think this point/argument should be banned from this discussion. 
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