On Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei <kont...@beberlei.de> wrote:
> 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 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
