> On Apr 25, 2021, at 1:52 PM, David Gebler <davidgeb...@gmail.com> wrote:
>
> Still, all these problems are solved to the same degree if you add a
> #[Sealed] attribute to a class which has no functional impact. You have
> sufficiently indicated to any user that extending this class is not a
> designed feature and may cause backwards-incompatible breaks with future
> releases - in a way that both a programmer and IDE can reason about, which
> in PHP's context is what matters. Attributes arguably even have a greater
> qualitative advantage that they can be applied right down as far as
> individual method parameters.
In my experience, if a developer needs access to a feature that is easily
available via the use of a method that is merely documented as internal-use
only, the developer will use it rather anyway than spend a lot more time trying
to work around what that method makes easily available. Especially if that
documented internal-use only is about not subclassing.
And if many other developers do that, the original developer will still have
the same problem as if they didn't document it as internal-use only.
But I do acknowledge your experience might be different. FWIW.
> In Java the idea of final and sealed classes makes more sense, since we
> actually to some extent need the compiler to be able to reason about these
> types and can gain optimization and code generation benefits from its being
> able to do so. PHP's concept of typing and implementation of type checking
> as an interpreted language is completely different.
>
> I wonder, if final and sealed as language constructs really offer the
> guarantees about intent and safety their advocates say they do, why are
> they not the default? Why can no one point me to a language where I have to
> write something like
>
> extendable class Foo permits all { .... }
>
> (and there are people who would be in favour of making inheritability this
> explicit, but I'm not one of them)
Well, I can't point you to a language that works that way because I don't know
more than a handful of languages in depth — although there may be one — but I
can point you to a language that does not even allow you to subclass: Go.
The Go designers wanted to get away from the fragile base class problem so they
provided embedding instead:
https://medium.com/@simplyianm/why-gos-structs-are-superior-to-class-based-inheritance-b661ba897c67
I program more in Go now than in PHP, and I can confirm that its approach works
brilliantly. Better IMO than what PHP currently offers in that respect.
> It's one thing as an author of code to say "I only intended and support
> this finite set of use-cases", it's quite another to say "and you should be
> impeded from proceeding with any legitimate use-case I didn't imagine or
> foresee"
I do respect that as a user of other developer's code you might view it that
way.
But then I also can respect the library or framework developer who chooses to
make their own job less difficult by (wanting to) mark a class to be sealed.
You claim "it's quite another thing to say" but I don't think a developer of
library or framework code should be required to offer features to their users
they do not want to offer. It is the developer's prerogative; if they want to
be able to mark their classes as sealed they should be empowered to do so.
IMHO, anyway.
> In practice, the only thing I've ever seen this achieve is to create
> difficulties, while the claimed benefits can be adequately (and better)
> achieved through existing patterns like annotations, interfaces and DI.
I would argue that maybe the reason you have only seen it create difficulties
is because of your own perspective and experiences that are, by definition,
anecdotal and thus limited.
OTOH Fabien Potencier and/or Taylor Otwell might have a different experiences
and thus a different perspective on what those benefits are (but I am
admittedly just hypothesizing here.)
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
