Re: [RFC][Draft] Sealed Classes

On Tue, Apr 27, 2021 at 2:57 PM Olle Härstedt <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 this > > 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 of > > line. > > > > That being said, David has never said he is against developers being able > > 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 strengths > > 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 = $logger; } public function value(){ if(null !== $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 > -- Chase Peeler chasepeeler@gmail.com