Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114211
To: David Gebler <davidgebler@gmail.com>
Cc: Guilliam Xavier <guilliam.xavier@gmail.com>,
 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>
 <722ed544-69e3-3be4-f828-185914617228@processus.org>
 <CA+p1FaZjWc+cMrfWkGP5LCmv6YOKF3h7dY_yYXxCmfUpRfp4fw@mail.gmail.com>
Message-ID: <818a7fa7-f76f-acb8-ef34-cabedc8c2ecc@processus.org>
Date: Tue, 27 Apr 2021 20:43:27 +0200
MIME-Version: 1.0
In-Reply-To: <CA+p1FaZjWc+cMrfWkGP5LCmv6YOKF3h7dY_yYXxCmfUpRfp4fw@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 à 19:51, David Gebler a écrit :
>> 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
The sealed feature does not enforce anything. It brings a new tool in 
already quite furnished toolbox. It doesn't force you to use it (and 
besides I think it's a good tool, but as I said, I can live without).
>> 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.

It's not enforcing one person's preference over another's, people should 
be able to seal whatever they want to seal in their own code. I repeat, 
their code, not yours. If you don't like another person's code because 
you can't override a class, then fork it or use another library. And 
beside, I doubt that people will use it so widely that it'll prevent you 
from doing anything good. Or if they do so, they are probably not 
writing a so good piece of software (beware, subjectivity in the last 
sentence).

By preventing so hard such feature to be included on this sole argument, 
you are actually dictating your own preference, not the other way around.

I think that sealed class usage remains an edge case, and it's basically 
meant to avoid users to shooting themselves in the foot and open the 
discussion when they think it's not a good choice.

>> 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.

I don't think it is, it's not how I understood it at the very least.

Please don't take anything I said as being disrespectful (I'm not a 
native english speaker and sometime I do not measure my own words), on 
the contrary it's an interesting discussion.

Regards,

--

Pierre