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

Reply via email to