Saying "the syntax makes my eyes bleed" is slightly useless feedback.
You could say "it's hard to scan", but I don't even think that's true – prepending everything << makes it easy to pick out attributes in plain text at a glance, and one can assume that IDEs will help even further. Additionally this syntax has effectively been battle-tested at scale already in PHP-like codebases – thousands of engineers at Facebook and Slack have used it over the last few years, and been productive with it. On Mon, 9 Mar 2020 at 21:02, Mike Schinkel <m...@newclarity.net> wrote: > > On Mar 9, 2020, at 10:42 AM, 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 > > > > A working patch is at https://github.com/beberlei/php-src/pull/2 though > > work around the details is still necessary. > > > > The RFC contains a section with common criticism and objections to > > attributes, and I hope to have collected and responded to a good amount > > already from previous discussions. > > > > There is also a fair amount of implementation detail still up for debate, > > which is noted in "Open Issues". I have pre-committed to one approach, > but > > listed alternatives there. On these issues I am looking for your > feedback. > > > > greetings > > Benjamin > > I am very excited to see this. I make heavy use of pseduo-attributes in > both PhpDoc and using class constants, and having real attributes would be > quite the boon. > > I do have a few concerns. > > 1. The syntax makes my eyes bleed. > --------------- > > I find angle brackets extremely hard to read and fear — have trained many > newbies in programming — that it will cause newbies who see PHP to think it > is too complex for them to consider learning. > > You mention that the good symbols are taken, but why limit ourselves to > symbols? Why not use words like PHP uses for other parts of the language? > > So instead of: > > <<SingleArgument("Hello")>> > <<Another\SingleArgument("World")>> > <<\My\Attributes\FewArguments("foo", "bar")>> > function foo() {} > > Why not use?: > > attribute SingleArgument("Hello") > attribute Another\SingleArgument("World") > attribute \My\Attributes\FewArguments("foo", "bar") > function foo() {} > > If we don't want to make attribute a keyword, why not this?: > > function attribute SingleArgument("Hello") > function attribute Another\SingleArgument("World") > function attribute \My\Attributes\FewArguments("foo", "bar") > function foo() {} > > Or?: > > function attributes > SingleArgument("Hello"), > Another\SingleArgument("World"), > \My\Attributes\FewArguments("foo", "bar") > function foo() {} > > Alternately, why not use this (which is probably the best option IMO)?: > > function foo() attributes > SingleArgument("Hello"), > Another\SingleArgument("World"), > \My\Attributes\FewArguments("foo", "bar") {} > > > 2. How do your attributes relate to traits and interfaces? > --------------- > > I assume that anything you could do in a class you could do in a trait, > but what about interfaces? > > Using my syntax, could we have attributes defines in an interface and then > require them to be implemented? For example, > > > interface Storable attributes > StorageEngine(string $engine), > DoNotTestMethodsPrefixedWith(string $prefix){ > function store() attributes PermissionsRequired(string $role) {} > } > > When implemented that might look like this: > > class AdminOnly() implements Storable attributes > StorageEngine("mongodb"), > DoNotTestMethodsPrefixedWith("_"){ > function store() attributes PermissionsRequired("admin") {} > ... > } > > Other than those two concerns, I'm sold! > > -Mike > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
