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