TRPL

Because I'm currently working on gathering all annotation types (or as many as I can find), this idea was brought up. Basically, we should provide a bit less freedom when declaring annotations by constructing an Enum with all annotations that are of interest. Constantin/Ovidiu, feel free to add other information points to this discussion.

The main reason is the performance of the AnnotateAst.annotations map - this was optimized in the past, especially putAnnotationImpl, but it doesn't reduce the overhead of the map lookups and string intern'ing. The performance hit was observed when profiling customer applications.

We already have a AnnotatedAst.runtimeAnnotations which is meant as an optimization for dynamic conversion. Having static IDs for all annotations will allow us to use an array or other fast collection to set or get them. In the .ast file, we will still save the 'annotation name', and not its ID, the same way as we do for the token type at the AST node.

Main goal is to improve performance for both the static and dynamic conversion. Additionally, we can analyze which annotation can be dropped or refactored, once we have a complete list.

Something else to keep in mind are the 'by-rule' annotations, which are emitted only for -Drules.tracing=true conversion mode.

It is an interesting idea.

Pros:

• There would be a simple way to check if an annotation name was valid.
• Performance as noted above.

Cons:

• Our AST classes and TRPL processing is meant to be independent of projects like FWD. Putting compile-time restrictions on annotation names is a problem since there may be many projects using our ASTs. How would we make the annotation names customizable by project?

I was envisioning a different idea about annotations. My thought was that we should declare the annotations used by a TRPL ruleset, in the top of that ruleset. Then we could add annotations operators to TRPL, or possibly treat annotations like named properties of an AST. The idea is to allow more natural access to annotations from rules. The operator approach might be something like node:annotaton_name, while the property approach would be node.annotaton_name. The operator idea opens up possibilities for handling common cases like null checks. The annotation declarations themselves would have the name, type, maybe a default value.

If the point is for TRPL to be independent of what the annotations are, can a provider for the annotations be plugged into TRPL?

If the point is for TRPL to be independent of what the annotations are, can a provider for the annotations be plugged into TRPL?

Yes, except that it adds a requirement for Java code in order to use custom annotations.

• For lighter weight TRPL usage, it would be more painful.
• For big projects like FWD, there already is a lot of Java code.
  • Not all users will be comfortable making edits.
  • Even for users that are capable of making those edits, it may not be convenient to do so. Custom conversion rules in FWD would be an example of a problem area. Users would have to make a patch to FWD or they would have to carry around Java code to do this.

This is why I prefer the idea of TRPL syntax to register these things at the rule-set level. It is readible, easy to maintain and easy to implement as a developer.

Even if we went the provider way, we'd have to support multiple providers. FWD itself has different AST types (Progress, Java...) and the annotations list would be different between them.

We need to post that somewhere else, it has customer table names in it. Also, this is better done in a FWD sub-project since these annotations are nearly all FWD-specific.

A key point highlighted here: some of our annotation names in FWD are dynamic and we use customer symbols in the names.

Greg Shah wrote:

We need to post that somewhere else, it has customer table names in it. Also, this is better done in a FWD sub-project since these annotations are nearly all FWD-specific.

I can upload it somewhere else, no problem, just let me know where.

Remove the customer-specific stuff (you can leave behind description of what was removed) and post it in #9721.

Radu,
I had peeked at the list you compiled. I am puzzled by something: why are there customer-specific values saved into the ASTs as keys? I understand that these should be the values of annotations (like legacy 4GL names, Java property names, original database/table/field names, or SQL column names), but not the keys.

Ovidiu, I will be honest, I don't know. I just created a patch that prints the keys in a file, and that's it, I didn't look at the meaning behind them.