On Mon, Aug 17, 2020, 4:07 PM 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:
> > > However, ending delimiters in PHP have little to do with how "complex"
> > > a syntax construct is (which is a rather loose definition, anyway).
> > > As I've pointed out before, standalone statements and declarations
> > > generally require an end symbol, but modifiers before a declaration
> > > do not. Attributes fall into the latter category, and therefore the
> > > lack of an end delimiter is consistent.
> >
> > A docblock is also a "modifier" under your declaration and it has an
> > ending symbol.
>
> The difference is that a docblock comment is also a standalone
> declaration - it's quite common to add one at the top of a file
> that doesn't modify any other declaration.
>
Doesn't matter that you can add them anywhere.
Internally, doc comments (on structural elements) are stored and handled by
Reflection the same way that attributes are.
> > The RFC gives a definition of the complexity as just a token vs a
> > set of name, arugment_list and constant expression parser rules. It
> > shows an example porting an ORM\JoinTable Attribute, which has
> > arguments, named parameter usage, complex definitions of default
> > values (Strings, arrays).
> >
> > This piece of code probably touches 10-20 parser rules.
> >
> > Most modifiers don't even have a parser rule, as they only match
> > their token.
>
> In this comparison really the only "complex" part of an attribute is
> the argument list, which already has its own start and end delimiters.
> So I don't really see the need to add another end delimiter after the
> argument list end delimiter
>
Again, in the future we might introduce a new feature that might make
attributes have more complex parts than just an argument list. In this
case, `@@` or `@:` is only going to f*** us up.
> > Types are missing indeed, and they are more complex than a simple
> > token, but less complex than attribute declarations.
> >
> > I guess the difference is that union types are new, and type
> > definitions used to be simple. Attributes however are *new* and
> > already complex, so we still have the option of always enclosing
> > them.
>
> An attribute without arguments has essentially the same complexity
> that a type declaration has always had. The only part that is more
> complex is the optional argument list, which as stated before has
> its own start/end delimiters.
>
> > > The RFC suggests a benefit of "Consistent colouring for being an
> > > end of the attribute syntax and the keywords in between can use
> > > different colors." I don't really understand this argument. How
> > > would an end delimiter change the syntax highlighting provided by
> > > IDEs?
> >
> > If you consider the three elements of an attribute declaration:
> > 1. Syntax for Attributes 2. Atttribute Name 3. Arguments then if
> > you color them in three different ways, then with an ending symbol
> > it improves the human readability to have the end be in the same
> > color [as] the beginning.
>
> I see what you mean now. Personally I don't think a differently
> colored end bracket will be particularly helpful to readability,
> though. IDEs will already highlight the argument list start/end
> delimiters, and the different coloring of an attribute name from
> whatever token follows it will ensure readability whether there is
> an argument list or not. Ultimately perspectives on readability will
> differ, though, since it's a somewhat subjective consideration.
>
> > > ## 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.
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
