Am 26.04.2021 um 14:18 schrieb Ilija Tovilo <tovilo.il...@gmail.com>:
> The point of sealed type is to fix the number of subclasses a given
> type can have, which means you can handle a value by type (as that
> list is not finite). Code that handles Optional values could look like
> this:
>
> ```
> if ($option instanceof Option\None) {
> throw new Exception();
> }
>
> // We now know the value is a Some
> var_dump($option->value);
> ```
I really hope that's *not* the way people will use the Maybe type....
> If you suddenly provide your own version of None the code above will
> break.
... but no, it wouldn't break, as MyNone extends None, so instanceof would
still work.
> To most people it's obvious that you can't add new cases to an
> existing enum.
The RFC does not mention data classes (at least not explicitly), it talks about
sharing common functionality.
So I think you're somewhat moving the goal posts.
If you want to limit Enums only then I would have to reconsider, but we were
talking about generic classes AFAIK.
> It doesn't sound sensible to add logging to a data
> class. That's something that belongs into a hook or service of some
> kind.
You're again making assumption about what's sensible for the user of a library,
that's the mind-set I would like to avoid.
> People might also want to use sealed for behavioral classes, the use
> case here is the same as final. Final is not here to make your life
> harder. It's here to make the lives of the library maintainers easier.
First of all: Yes, I'm no fan of final either.
I've encountered enough examples where it *did* make my life harder.
And as a library writer myself I value the user experience higher than the
library developer work because there are (hopefully) a lot more users than
developers.
> If they have to reason about every way a method could be overridden,
> every change in the library would become more risky, require more
> thought and more frequent major version updates.
A properly designed API should be simple and stable enough to not need this
kind of safe-guards.
Overly complicated, cathedral-style frameworks might yearn for it but I think
it's addressing the symptoms, not the cause (-:C
> This means more work and less features for you, too.
That kind of argument reminds me of people saying that user tracking is a good
thing because I get to see more relevant advertisement.
You're a good sales-man though, I give you that, but you haven't convinced me
yet ;-)
- Chris
