Re: [RFC] Shorter Attribute Syntax Change RFC 0.2

On Mon, Aug 17, 2020 at 5: 14 PM Theodore Brown <theodorejb@outlook.com> wrote: > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown <theodorejb@outlook.com> > wrote: > > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei <kontakt@beberlei.de> > wrote: > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown <theodorejb@outlook.com> > wrote: > > > > ## Potential Future Benefits of Enclosed Delimiter Syntax? > > > > > > > > The RFC shows an example of a potential "simpler" attribute using a > > > > string instead of a class name. I honestly have no idea what this is > > > > supposed to do or what benefit it would have over normal attributes. > > > > > > > > The concept of attributes being a class name with optional arguments > > > > has been proven over many years by its use in docblock annotations, > > > > and if there was some deficiency in what this syntax allows it seems > > > > like we would have discovered it by now. > > > > > > I agree on just the string, but a closure would make 100% sense for > > > a decorating feature. Javascript and Python "Attributes" work as > > > decorators, i.e. they get called around the decorated function. > > > > > > It is not a completely unrealistic feature to think off: > > > > > > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)] > > > function foo($message) {} > > > > As I understand it JavaScript decorators do not use anonymous > > functions for decorators like this, though. Instead you would make a > > named function and apply it with @myFunc() before the > > decorated > > function or class. > > > > Presumably we could accomplish the same thing in PHP with e.g. an > > __invoke method in the attribute class, without > > complicating the > > attribute syntax itself. > > One other thought on this. I agree that decorators are not a > completely unrealistic future feature. However, it must be noted that > both JavaScript and Python use the @Attr syntax for decorators, > and > the lack of an end delimiter in no way precludes this usage. > Yes they support decorators with @, but they don't support metadata. With this syntax its either or, because from @Attr only you cannot decide if its a decorator or a metadata attribute. It would not work by detecting __invoke on the Attribute, because the whole architecture of Attributes is based on deferring autoloading until Reflection*::getAttributes(). But when you use decorators, you would need to know this at runtime, so the zend_attribute datastructure would need to know its not an metadata attribute, but a decorator. > The whole point of a decorator is to offer syntax sugar for a common > reusable pattern (pass a function/class to another function which can > add additional information or behavior to it). It's not clear how an > anonymous closure would be useful for this, since it would not allow > reusability, which defeats the purpose. > > So the argument that an end delimiter has "potential future benefits" > still lacks any realistic examples, and is countered by years of > proven usage of the @Attr syntax in docblocks and other > languages. > > Sincerely, > Theodore