javac's allparams(): returns type arguments, yes?

[Maurizio Cimadamore]

Hi,
the naming of these methods is unfortunate, and has been like that for a 
very long time (historical reasons lost in time). Remember that the core 
of the javac implementation is based on a compiler that was written 
before JLS 5.0 was finalized, so some of the terminology was still in 
flux, which resulted in some of the methods not having the "correct" 
name (as per JLS).

You are correct in pointing out that both `allparams` and 
`getTypeArguments` are really about "type arguments" (use site).

The only difference is that the former only returns the type arguments 
of the generic class type (or generic method) it is called on, whereas 
the latter will recurse up to the outermost generic type (and return 
_all_ the type arguments - this is useful e.g. when performing type 
susbtitution).

In this vein, the "typarams_field" name is also obviously wrong, and it 
is really a "type argument cache".

P.S.
We will gladly accept PRs which rectify the status quo (given we just 
forked 22 from 21, now it would be a good time for such sweeping changes 
too) :-)

Cheers
Maurizio


On 13/06/2023 18:01, Laird Nelson wrote:
> I am reading some javac code to satisfy some curiosity and wanted to 
> quickly confirm something.
>
> I noticed that the com.sun.tools.javac.code.Type#allparams() method 
> actually operates on type *arguments*, correct, despite its name 
> implying (to me, used to the Java language model terminology) otherwise?
>
> So in the case of a type representing Outer<String>.Inner<Number>, 
> allparams(innerType) would presumably return the String and Number 
> type *arguments*, and not the formal type parameter elements (S and N 
> or whatever) corresponding to them?
>
> Related: the getTypeArguments() method works on a field called 
> typarams_field; I'm assuming again that the typarams_field field 
> stores type *arguments*, not formal type parameter elements?
>
> L