Stitching together 2 replies to minimize thread noise...
On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote:
> Speaking of Attributes I prefer not to use an Attribute for any particular
> language feature which expects input arguments to be a valid class or
> interface name for two reasons: first because there is no effective way to
> restrict input string to be a valid class or interface name and second that
> it'd require passing strings which means in most cases passing class or
> interface name with magic ::class constant read.
>
> Cheers,
> Michał Marcin Brzuchalski
That's actually a pretty solid argument against attributes here, honestly.
Consider me convinced, and now in favor of "final class Foo permits Bar, Baz".
:-)
On Sun, Apr 25, 2021, at 12:52 PM, David Gebler 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 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)
>
> 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"
>
> 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.
Part of the challenge here, i think, is that PHP, like most classic OOP
languages, uses the same syntax for two different things. One is for product
types (an int combined with a string together in a single struct), the other is
bound values in closures (aka, methods in service objects). That's arguably by
design in classic OOP, and arguably a design flow in classic OOP. :-)
I can think of no reason at all to make a service object's class sealed. For
those, yes, you shouldn't forbid custom extension, and frankly I usually
discourage the use of private variables, too, for the same reason.
For product types that are part of the domain, however, there are definitely
use cases where you want a defined finite list of possible variants. The
Distance and Maybe examples upthread, for instance. That's not always the
case, but there are definitely cases for them.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
