Re: [RFC] Shorter Attribute Syntax Change RFC 0.2

On Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei <kontakt@beberlei.de> wrote: > 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 wrote: > > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote: > > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown 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. Hi Benjamin, That's true. Due to deferred loading we would need some kind of new syntax to denote checked attributes or decorators, *regardless of whether the attribute syntax has an end delimiter*. As I've suggested before, we could potentially denote checked attributes in the future like this: @@!Attr("some val") function foo() {...} I still believe that using an inline closure attribute syntax like the example in the RFC would not be a good solution for decorators, as it reduces reusability and readability, and would prevent applying a decorator that includes metadata. Best regards, Theodore