On Mon, Aug 17, 2020 at 5:
14 PM Theodore Brown <theodor...@outlook.com> wrote:
> On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown <theodor...@outlook.com>
> wrote:
>
> > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei <kont...@beberlei.de>
> wrote:
> > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown <theodor...@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
