On Wed, 8 Feb 2023 07:24:05 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> **Specification:**
>>
>> MethodSignature:
>> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
>>
>> Result:
>> JavaTypeSignature
>> VoidDescriptor
>>
>> ThrowsSignature:
>> ^ ClassTypeSignature
>> ^ TypeVariableSignature
>>
>>
>>
>> **Reflect in API mapping:**
>>
>> public sealed interface ClassTypeSig
>> extends RefTypeSig, ThrowableSig
>>
>> and
>>
>> public sealed interface TypeVarSig
>> extends RefTypeSig, ThrowableSig
>>
>> and
>>
>> /**
>> * @return method signature
>> * @param typeParameters signatures for the type parameters
>> * @param exceptions sigantures for the exceptions
>> * @param result signature for the return type
>> * @param arguments signatures for the method arguments
>> */
>> public static MethodSignature of(List<Signature.TypeParam>
>> typeParameters,
>> List<Signature.ThrowableSig> exceptions,
>> Signature result,
>> Signature... arguments) {
>>
>>
>> `Signature.ThrowableSig` is a `Signature` and it is a common super of
>> `ClassTypeSig` and `TypeVarSig`.
>
> `TypeParam` is not a signature, because it simply is not a signature.
> Per spec:
>
> TypeParameter:
> Identifier ClassBound {InterfaceBound}
> `Signature.ThrowableSig` is a `Signature` and it is a common super of
> `ClassTypeSig` and `TypeVarSig`.
I really don't follow here. ThrowableSig is a piece of a method signature,
which starts with "^" and is followed by either a class or a typevar signature.
You can never encounter it from the toplevel JavaTypeSignature production. It's
ok (as I have said) to have a ThrowableSig element in the API to model the
production, but that element should not be a subtype of Signature (at least not
if Signature, as you claimed is meant to model the JavaTypeSignature
production). That is, there's no "is a" relationship between JavaTypeSignature
and ThrowableSig (at least not that I can see when looking at the productions).
-------------
PR: https://git.openjdk.org/jdk/pull/10982
