[code-reflection] RFR: JavaRef extends TypeElement

[Paul Sandoz]

On Wed, 30 Apr 2025 09:11:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Each implementation of `JavaRef` supports an external form, using the sigil prefix `&` to indicate a reference of some kind.
>> 
>> The externalized form of `TypeVarRef` is changed to be uniformly structured. This required update to the code model text of a few tests. Arguably we are taking a step back in terms of readability, but we can address that later - it was easier to update a few tests rather than preserve the existing encoding in a few places.
>> 
>> We still rely on the bespoke string form for java refs, which is used as the value of an externalized attribute. Ideally such attribute values are either instances of `JavaRef` or `ExternalizedTypeElement` to be transformed into the appropriate `JavaRef`. We can address that later to further separate out parsing.
>> 
>> I believe we have what we need to further enhance the code model builder to not rely on bespoke parsing logic of types and refs. We can either construct `ExternalizedTypeElement` tree instances explicitly or parse from a very simple grammar. If we are careful i believe we can share the results of nested type elements if reused e.g. as in `List<Double>` and `Set<Double>`.
>> 
>> More generally it now means we can generate a simple s-expression-like tree for the whole code model, e.g., a string where the `(` and `)` characters represent tree structure and say `L` represents a leaf node, and a list of leaf node values in topological order.
>> 
>> --
>> 
>> Below is the type grammar, which i believe is consistent with what we have implemented.
>> 
>> # Type element grammar
>> 
>> ## General structure
>> 
>> 
>> identifier
>>   string
>> 
>> name
>>   identifier
>> 
>> sigil
>>   # | . | & | + | - | [
>> 
>> type
>>   sigil
>>   identifier
>>   sigil identifier
>>   identifier < types >
>>   sigil identifier < types >
>> 
>> types
>>    type
>>    type , types
>> 
>> 
>> ## Core types
>> 
>> 
>> varType
>>   "var" < type >
>> 
>> tupleType
>>   "tuple"
>>   "tuple" < types >
>> 
>> funcType
>>   "func" < types >
>> 
>> 
>> # Java types
>> 
>> 
>> javaType
>>   primitiveType | classType | wildCardType | arrayType | typeVariableType
>> 
>> javaType-no-wildCardType
>>   primitiveType | classType | arrayType | typeVariableType
>> 
>> primitiveType
>>   boolean | byte | ... | void
>> 
>> classType
>>   name
>>   name < paramTypes >
>>   . < enclosingType , innerType >
>> paramTypes
>>   javaType
>>   javaType , javaTypes
>> enclosingType
>>   classType
>> innerType
>>   classType
>> 
>> wildcardType
>>   + < wildcardTypeBound >
>>   - < wildcardTypeBound >
>> wildcardTypeB...
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/type/TypeVarRef.java line 117:
> 
>> 115:     public String toString() {
>> 116:         // @@@ required to pass TestJavaType.java
>> 117:         return name;
> 
> What should the `toString()` method in JavaType do? Should they return a human readable representation that will then be embedded in the code model (e.g. when calling `toText`) ? Or should we also have `toText` on all `TypeElement`s ?

Hmm... in this case `toString()` seems appropriate to return a human readable representation (that `OpWriter` writes and `OpParser` parses, but we don't have to specify the grammar), given that i would not expect these strings to be very large, unlike the text of code models.

(The comment indicates some testing modifications would be required for type variable types.)
The default implementation of `TypeElement.toString` could be `return externalize().toString()`.

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/416#discussion_r2069209651