I’ve been away from the keyboard for a few months and am slowly getting back to work and I thought I’d celebrate by taking a closer look at the new annotation support that Grubba has put together. My plan is to have a “chapter” of material for a future edition of the pike manual.
What follows are a few comments as well some questions (possibly disguising a feature request or two).
1. I’ve noticed that annotations(something, 1) returns annotations associated not only with each identifier, but also with the class containing the identifier. For example:
class a {
@“foo”;
@“bar”: void gazonk() {}
}
annotations(a()) returns:
({ (<“bar”>) })
While annotations(a(), 1) returns:
({ (<“foo”, “bar”>) })
I don’t think I would have expected that behavior… I think I’d have been more likely to expect some sort of result that described annotations on the identifier of the present class versus annotations on the same identifier from any inherited class. I was just wondering if there was a particular use case where that might be handy?
2. I added Program.annotations() in order to query the annotations directly made on a program. I’m not sure that the additional flag argument works in a reasonable way: if set, Program.annotations(prog) displays the annotations for the entire inherit tree, whereas without the flag, only the annotations defined directly in the present program are displayed. That seems backward to me, but I did it that way to keep the “nature” of the behavior similar to annotations(), but it think that should be reversed in order to limit surprise. Thoughts?
3. Annotations currently must be constant expressions, and that works well for the builtin annotations, but it prevents annotations that take arguments, which is a pretty common use case in other languages. For example:
@Web.Routing(“/path/to/method”, Web.Method.GET): void my_method(object request) { … }
I looked a little more closely and realized that the built-in annotations are all classes. I was wondering what the benefit of that is versus being objects, the benefit/need for the expression to be constant, and whether it would be feasible to allow for “annotations with arguments” as described above.
4. I wonder if it would be possible to define a syntax (and possibly add placeholder functionality) for being able to annotate function arguments.
For example:
void foo(string a, @NotNull: string b) { … }
I realize there isn’t currently a framework in place for asking about the nature of an individual argument, but I can imagine the feature might be useful, is present in other languages that implement metadata and if we thought it were feasible, might be nice to define the syntax now. Any thoughts?
Apologies for all of the questions, I don’t recall all of the discussion over the years about this, and am attempting to map my C#/Java experience with metadata onto pike.
Thanks in advance!
Bill