Open DrSloth opened 3 months ago
There are two things here, one being able to get things with a particular attribute, one is to actually support data for those attributes. What is desired?
I think both would be handy. Extend user attributes to support data fields and then be able to query the user attributes and associated field values at runtime. I have been achieving something kind of resembling this with $exec and a bunch of nested macro calls to generate strings I pass to a tool which then generates constants/structs with the information. This works in a pinch but the attributes obviously aren’t next to the members directly, so it’s still a bit cumbersome.
I don't think that custom attributes should introduce runtime information though?
I don't think that custom attributes should introduce runtime information though?
I think it shouldn't by default. If the information should be queryable at runtime the user has to create a macro that generates arrays or maps from the attributes.
With the @tag
feature, do we have this now?
I think one thing that is missing is being able to get a list of all tags associated with a particular member or function.
Could use 'tagsof' to match the convention for members/methods? Perhaps value retrieval with 'tagof' is a confusing name then? Something like 'tagvalue' could be used for that?
This addition would then allow any desired runtime lookup stuff to be generated.
What would that feature be used for though? That isn't already covered by querying whether the tag is there.
@Dodzey ping
It would be a great feature to be able query attributes via reflection.
This could allow things like setting the names or formats of fields for certain serialization formats, grouping fields or giving information for other macros.