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