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.
> 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.
> 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
