Sorry… I didn’t include the list… feel free to chime in!

On Oct 22, 2020, at 2:35 PM, william@welliver.org wrote:

On 2020-10-22 05:45, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:

...

...

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:

That seems strange; don't you mean annotations(a()->gazonk) and annotations(a()->gazonk, 1) respectively above?

Yes, sorry, I was trying to minimize the amount of data I included in the email and didn't update the example code.

...

...

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?

The use case that I had in mind (as far as I recall) was using annotations for serialization metadata.

Ok, I guess I need to think about that a little more; I'm not sure I completely understand how that would be used. I might omit discussion of that flag until I know what I'm talking about ;)

...

...

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?

That does seem a bit backward.

I'll switch the behavior; I agree that the default no-flag behavior should show the roll-up, as that's usually what someone would expect to see.

...

...

3. Annotations currently must be constant expressions

...

Incorrect. All of the current annotations when used are objects. Eg: @Pike.Annotations.Implements(AbstractSimpleNode); A Pike-level class can be marked as creating constant objects using the "annotation" @constant; (which sets the PROGRAM_CONSTANT flag in the class).

Perfect! I was thinking there might be a way to specify this, I just couldn't put my finger on it.

...

...

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) { … }

NotNull seems to me to be a property of the type rather than the argument. I'm currently in the process of reworking the type checker, which would fix the issue that 0 is accepted everywhere.

Yes, that's probably true and perhaps a bad example. Here's one that uses the web request mapping idea I used in the original email (and that has real life analogs in Java and C#):

@Web.Routing("/search/results", Web.Methods.GET): string my_request(@Web.Request.Parameter("search_term"): string param1, @Web.Request.Parameter("max_items"): int param2) { ... }

I had been thinking that annotations on an argument might be somehow stored in the type, and that there would be a way to examine them, but I don't have a full proposal for how that would work (hence my suggestion to define a syntax and allow that to be valid as a first step.

As far as a proposal for the syntax, would having something along the lines of

annotation_list full_type optional_dot_dot_dot optional_identifier

Be reasonable for this purpose?

Bill