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

[Maurizio Cimadamore]

On Wed, 30 Apr 2025 18:08:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> 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()`.

The issue is that there is a clear tension between things being parseable and things being readable. If you want things to be parseable, you need to include all the information that is in the ref/type. For instance, a type-variable should have the owner printed out -- as well as the bound. But for a type-variable, a human readable representation would just expect to see the tvar name (and maybe the owner, at least in some ambiguous cases). But such a representation would be lossy, and not parseable.

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

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