on implementing state components as a first class concept

Joe Darcy joe.darcy at oracle.com
Thu May 2 18:06:50 UTC 2019


Hi Maurizio,

On 5/1/2019 9:02 AM, Maurizio Cimadamore wrote:
> On top of my head, the way I'd approach this would be something like 
> this:
>
> 1) keep using fields to model state components, but mark them with a 
> special flag
>
> 2a) use the same VarSymbol implementation for both the state component 
> and the field
>
> 2b) derive the state components from the VarSymbols marked with the 
> corresponding flag


The above is a summary of the initial implementation in the amber repo 
where the fields corresponding to the state components were marked with 
an ElementKind of STATE_COMPONENT rather than FIELD :-)

The basic design decision is how distinct the modeling of the state 
components should be from the fields holding the state information.


>
> 3) When users ask for state components 
> (TypeELement::getStateComponents), generate the list as per either 
> (2a) or (2b).
>
> Is this a viable implementation path?
>
> P.S.
>
> I'm a bit skeptical of reusing VariableElement for state components, 
> since that API is more general (e.g. see 
> VariableElement::getConstantValue()). I'd rather like to see a new 
> interface for state components, and maybe a common superinterface 
> between state components and field elements.


Based on experience with the apt API, the javax.lang.model API uses its 
interface types to cover a wider range of options. For example, there is 
one interface to model type declarations 
(javax.lang.model.element.TypeElement) rather than specialized 
sub-interfaces for enums, annotation types, etc. as was done in the apt 
API. Likewise, the VariableElement interface serves a spectrum of 
variable-related entities; from its summary "a field, |enum| constant, 
method or constructor parameter, local variable, resource variable, or 
exception parameter."

While it would be possible to add state components as a top-level 
modeling interface, alongside type, package, module, etc., I don't think 
it is necessary to do so.

Cheers,

-Joe



More information about the amber-dev mailing list