[code-reflection] RFR: JavaRef extends TypeElement [v2]

[Maurizio Cimadamore]

On Wed, 30 Apr 2025 18:45:13 GMT, Paul Sandoz <psandoz 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...
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up ConstructorRef

Honestly, I wonder if the concept of `JavaRef` still carry its own weight. What it it was just `TypeElement`/`JavaType` ? What if the hierarchy of Java "types" was just flat? My feeling is that if we introduce distinctions, then it's easy to see cracks -- such as the fact that records are refs, but classes are not -- or the fact that a type-variable is both a refs (it points to a type var decl), but also not a ref (it represents a type-variable _use_).

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

PR Comment: https://git.openjdk.org/babylon/pull/416#issuecomment-2843331390