pon., 9 mar 2020 o 15:45 Benjamin Eberlei <kont...@beberlei.de> napisał(a):
> 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 > > > > 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. > > > > Obviously I am looking for feedback on the whole RFC, not just the open > issues :-) > > > > > greetings > > Benjamin > > > Hi Benjamin, I'm really glad you're taking up the baton! IMHO a bunch of straw polls could provide a way more beneficial knowledge about feelings people who can vote up for this feature. What do you think? It could be good to discover the negative or positive feelings as well as "I'm not opposite" feelings. >From what I can see now and I didn't think of it earlier are some details but we should ask the question how far we wanna go with this feature for its an initial shape. Are we gonna provide complete attributes feature like C#, Java etc. which allows for annotating annotations (whatever it's called for me annotations/attributes has no difference for now) meaning they allow to put metadata which puts restrictions on: 1. Usage of the attribute should be allowed once or multiple times regarding the same target? 2. Targetting attributes should be annotated - no matter if through an interface or annotation? 3. Allow for inheritance should be annotated - meaning when reading attributes for class Bar which extends Foo on which attributes are set, should I get attributes or not? 4. Should attributes be resolvable all the time, what if the class won't exist on runtime? In some languages like Java there are for eg. documentary annotations which live with code but are not stored on runtime. Or we simply want to provide a simple way of retrieving the metadata from class/trait/interface/properties/methods/functions without checking their repeateness, without inheritance, without validating the targets where they appear, and just allow to move any kind of attributes into the language and allow the userland to decide what to do with them and how to handle them properly? The thing which I haven't consider earlier and I find it nice features is the ability to filter annotations against some abstract/base annotation - it may be described as a better cause I do feel like it should be done through extending of the interface and not by an abstract class. Like from the RFC itself the `\Validator\Attributes\Attribute::class` it wouldn't make sense for it to be a class, not even an abstract class, there's probably no method which this abstract will provide. Attributes should be forbidden for instantiation and this if funny cause they do have a public __construct so they look like classes but are not actually classes which you should be allowed to instantiate wherever you want, right? So we agree it looks a little weird here but dunno if there's something we can do. cheers, Michał Brzuchalski
