On Tue, 7 Feb 2023 12:10:43 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> The confusion come from simplified name. Signature probably should be called >> JavaTypeSignature according to the spec. ClassSignature and MethodSignature >> could not extend it, as it would not respect the reality. Each of them are >> completely different species. Signature (or JavaTypeSignature) on the other >> side has many sub-types. > > I think you mean `TypeSignature` from JLS 4.3.4 ? If so, I get it. To me it > looks as if "Signature" really means "TypeSignature" - then it would make > sense as to why `MethodSignature::arguments` returns a `List<Signature>` > (e.g. because it should be `List<TypeSignature>`, as in the spec). > > Also, from a modelling perspective, I see other problems too - in the JVMS, > type signatures are defined as follows: > > > TypeSignature: > FieldTypeSignature > BaseType > ``` > And: > > > FieldTypeSignature: > ClassTypeSignature > ArrayTypeSignature > TypeVariableSignature > > > So I'd roughly expect a type with 4 subclasses (type, then class <: type, > array <: type, tvar <: type). > > But the Signature class currently has other subclasses too - such as > `ThrowableSig` - which is really only an (optional) part of method > signatures. And, similarly, it also has `TypeParam`, which is a part of > method/class signature - but is _not_ a type signature per se. > > Summing up, it seems to me that the naming issue (which is not that > important) hides a bigger modelling issue. Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1) ------------- PR: https://git.openjdk.org/jdk/pull/10982
