On Fri, Apr 17, 2020 at 6:11 PM Theodore Brown <theodor...@outlook.com> wrote:
> On Fri, Apr 17, 2020 at 5:49 AM Benjamin Eberlei <kont...@beberlei.de> > wrote: > > > As there has only been minimal new discussion after the last changes to > the > > RFC I wanted to give a heads up that I will open the vote on Monday > > afternoon. > > > > If you have further remarks or questions about the RFC, please let me > know. > > > > On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei <kont...@beberlei.de> > wrote: > > > > > Hi all, > > > > > > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in > > > 2016 with a few changes, incorporating feedback from the mailing list > back > > > then and from talking to previous no voters. > > > > > > The RFC is at https://wiki.php.net/rfc/attributes_v2 > > Hi Benjamin, > > Thanks for working on this RFC. I have a couple questions and > thoughts about the proposed syntax options. > > First, the RFC says that the alternate T_ATTRIBUTE `@:` token has the > downside "that it does not permit whitespace in attribute names to > allow detecting the ending of the declaration." Can you provide an > example of an attribute name containing whitespace that would be allowed > with the shift left/right tokens but not with the attribute token? > This is about whitespaes between token and attribute name, so "@:Foo" is allowed but "@: Foo" is not. Whereas with the hugging As, <<Foo>> and << Foo >> is allowed. This might come in handy if potentially we allow grouping attributes in the future such that: << Foo("bar", 1+1), Bar("baz", 2+2) >> > The RFC says that "Semantically the attribute declaration should be > read as instantiating a class with the attribute name and passing > arguments to the constructor." But class names can't contain spaces, > so how is it a downside for attribute names to not permit them either? > It seems like it would be a massive footgun to allow attribute names > that *can't* resolve to a class name, since there would be no way to > migrate them to a declared attribute class without a BC break. For this > reason, regardless of the final syntax choice I think whitespace should > not be permitted in attribute names. > This paragraph becomes a non-issue then, the attribute names themselves don't have spaces in them, so they are always valid. > > Secondly, given that attribute arguments are evaluated as constant > expressions, it's far easier for me to read the T_ATTRIBUTE `@:` syntax > at a glance than the syntax reusing shift left/right tokens. With the > latter my eyes tend to confuse shift left/right tokens in a constant > expression with the open/close token of an attribute (especially since > the syntax using bit shift tokens allows multiple attribute declarations > on the same line). > > Consider this example using the shift left/right token syntax: > > ```php > <<BitShiftExample(4 >> 1, 4 << 1)>><<OtherAttribute(4 >> 1, 4 << 1)>> > function foo() {} > ``` > > To me the same thing using the T_ATTRIBUTE syntax is far more readable: > > ```php > @:BitShiftExample(4 >> 1, 4 << 1) > @:OtherAttribute(4 >> 1, 4 << 1) > function foo() {} > ``` > This is a personal assumption here, but I would assume 95% of developers have never used >> or << before or for a long time and maybe 80% don't even know what bit shift means and how it works. I would think nobody needs this in attributes. The syntax is a secondary vote though, so you can just vote your preference :-) > Best regards, > Theodore >
