You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to #9322, but for the annotations themselves. Currently annotation types are only referenceable by their hard coded name. It would be nice if they were also in a type hierarchy similar to classes and structs so that Annotation.subclasses could be used.
However, in order to not make the return value of the hash one big union, I used overloads on the annotation type to allow the compiler to know what "type" the hash value will be. See https://github.com/athena-framework/config/blob/master/src/annotation_configurations.cr#L55. This works fine at the moment since I also need the same array for reading them; but in the future when that is no longer required, I would now not have a good way to define those overloads.
I think this would also be a good future proof feature as if the annotation type is merged with the data that should be read off of it, like PHP does, then this could also be expanded to also support all_subclasses if inheritance is supported in the implementation.
Similar to #9322, but for the annotations themselves. Currently annotation types are only referenceable by their hard coded name. It would be nice if they were also in a type hierarchy similar to classes and structs so that
Annotation.subclasses
could be used.The main use case I have in mind relates to what I did as part of https://dev.to/blacksmoke16/utilizing-macros-annotations-in-a-web-framework-part-2-1453#annotation-data-at-runtime. The tl;dr is that it allows you to register annotations via a macro to try and read them off an instance variable, type, or method in order to expose them at runtime in a hash. This side of the use case would be solved as part of #9322.
However, in order to not make the return value of the hash one big union, I used overloads on the annotation type to allow the compiler to know what "type" the hash value will be. See https://github.com/athena-framework/config/blob/master/src/annotation_configurations.cr#L55. This works fine at the moment since I also need the same array for reading them; but in the future when that is no longer required, I would now not have a good way to define those overloads.
I think this would also be a good future proof feature as if the annotation type is merged with the data that should be read off of it, like PHP does, then this could also be expanded to also support
all_subclasses
if inheritance is supported in the implementation.EDIT: Related https://forum.crystal-lang.org/t/rfc-annotations-metadata-declaration-dsl/1312/7?u=blacksmoke16
The text was updated successfully, but these errors were encountered: