[foreign-jextract] RFR: Represent typedef with Declaration.Variable instead of Declaration.Scoped

[Maurizio Cimadamore]

On Thu, 30 Apr 2020 16:50:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> I disagree (pretty strongly) with the direction proposed in this patch. Making a `typedef` a variable is a workaround.
>>> Under no circumstances you can get a value out of a typedef - a typedef does not model a variable, and trying to bend
>>> the API to do so is, IMHO, wrong.
>> 
>> While I agree with your statement, the Declaration.Variable API doesn't present a value(), only Constant has a value().
>> 
>> In a sense, type() is the value of a Type declaration.
>> 
>>> To me the big issue is that a typedef declaration, as it stands, is only good to wrap a declaration. But the solution I
>>> think, would be to have a more explicit `TypeDef` declaration tree, which has a name and a type (where the type can be
>>> a `Declared`, if need be).
>> 
>> As current Declaration.Variable stands, it's perfect, with name(), type() and kind(). We can either create a different
>> interface, or rename to something else if that helps.
>
>> As current Declaration.Variable stands, it's perfect, with name(), type() and kind(). We can either create a different
>> interface, or rename to something else if that helps.
> 
> Variable is perfect in the sense that it has the right structure. But it's not at all what a typdef is! Imagine I write
> a visitor for the declaration API: if I see vistVariable and I'd expect to see a global, or a struct field, I would now
> have to defend _against_ typedefs?  From a logical point of view a typedef has nothing to do with a variable
> declaration, so a new `Declaration.Typedef` interface would be preferrable

> Sure. We should add a new Visitor method as well?

I think so.

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

PR: https://git.openjdk.java.net/panama-foreign/pull/137