Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114213
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> <CA+p1FaZjWc+cMrfWkGP5LCmv6YOKF3h7dY_yYXxCmfUpRfp4fw@mail.gmail.com>
 <CAAKU0u=MrTOCME-omM0Vh_j2Wwu89V6+gWp8eJj19MweJ00vHw@mail.gmail.com>
 <CAPKYkKyRWmpByUrtjJ7U67gdj8a7eM0kE-qxKPnLLEsVFQkZ3w@mail.gmail.com> <CAJpLVh37Lq44sDSKDCqBk1HKtML1dyu0v4+V8LBSr8Hnu67KoQ@mail.gmail.com>
In-Reply-To: <CAJpLVh37Lq44sDSKDCqBk1HKtML1dyu0v4+V8LBSr8Hnu67KoQ@mail.gmail.com>
Date: Tue, 27 Apr 2021 15:07:28 -0400
Message-ID: <CAPKYkKx77Q0WFvJdQ7ag9wvLNYM5r9xkrPRWER1pHBr8KH_08Q@mail.gmail.com>
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, David Gebler <davidgebler@gmail.com>, 
	Pierre <pierre-php@processus.org>, Guilliam Xavier <guilliam.xavier@gmail.com>, 
	Christian Schneider <cschneid@cschneid.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e622e105c0f8f916"
Subject: Re: [PHP-DEV] [RFC][Draft] Sealed Classes
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000e622e105c0f8f916
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 27, 2021 at 2:57 PM Olle H=C3=A4rstedt <olleharstedt@gmail.com>
wrote:

> 2021-04-27 20:17 GMT+02:00, Chase Peeler <chasepeeler@gmail.com>:
> > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals <
> > internals@lists.php.net> wrote:
> >
> >> I think the conversation on final classes being "bad" has gone on long
> >> enough. You don't like final, and you don't want to see more features
> >> like it being added, such as sealed. Point taken. Now please stop
> >> dominating the discussion, thank you.
> >>
> >>
> > I think the legitimacy of final/sealed classes goes to the heart of thi=
s
> > RFC. As long as people are going to discuss it and bring up counter
> points,
> > then I think asking someone to stop defending their view is a bit out o=
f
> > line.
> >
> > That being said, David has never said he is against developers being ab=
le
> > to annotate their classes as being final or sealed. He is just against
> the
> > engine enforcing such requirements. On this I agree. I understand that
> > other languages support this concept - and frankly, I don't care. The
> > flexibility that PHP offers has always been one of its greatest strengt=
hs
> > and this just further erodes that.
> >
> >
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: https://www.php.net/unsub.php
> >>
> >>
> >
> > --
> > Chase Peeler
> > chasepeeler@gmail.com
> >
>
> Sometimes it's helpful to apply a risk perspective the shed some light
> under hidden assumptions of different arguments. For example, what's
> the probability and impact of an event that would limit a coder when a
> library is using a sealed class? And the other way around, what's the
> probability and impact of an event that would decrease code quality
> when a sealed class is *not* used (like being able to subclass
> Maybe/Option even when it "shouldn't" be possible)?
>
>
As someone mentioned above, maybe they want to just add some logging
capabilities to maybe.
class MyMaybe extends Maybe {
  protected $logger;
  public function setLogger($logger){ $this->logger =3D $logger; }
  public function value(){
     if(null !=3D=3D $this->logger){ $this->logger->log("getting value"); }
     return parent::value();
  }
 }


> If the probability of such an event is high, but the impact to overall
> code quality is low, the risk is also considered low. (Example: Just
> create your own Maybe class. Of course harder with more elaborate
> classes, you don't want to copy-paste an entire library. And the other
> way, extending Maybe is a very local thing to do and doesn't hurt the
> library itself.)
>
>
Copy/pasting Maybe into my own MyMaybe class isn't going to be a valid
option if I encounter something like

function(Maybe $maybe){...}

If I can subclass Maybe, then it will work. If MyMaybe is a totally
different class, though, it won't.



> When both probability and impact are uncertain, it will make it harder
> to create consensus, and will make arguments more emotional or
> heuristic. When risk is low and the benefit high (and clear),
> consensus is easy.
>
> Olle
>


--=20
Chase Peeler
chasepeeler@gmail.com

--000000000000e622e105c0f8f916--