Class array implementation

[Janus Weil]

Hi Paul,

> The
> problem is that the insertion of the component references that point
> to the the _data field and the _vptr components (eg hash, size, copy
> and so on) is done too late; either in translation or the fimnal stage
> of resolution. This results in the ad-hoc aspect, since it has to be
> done differently for every situation.

Huh. In the scalar version of the CLASS implementation we rather had
problems in the opposite direction (i.e. class containers being
inserted too early).

I think I had started to look into the possibility of deferring class
container creation until resolution stage, but never finished it.

What does it make so much different in different situations? I had
introduced macros like

#define gfc_add_data_component(e)     gfc_add_component_ref(e,"_data")

to make this task a little easier.


> I am considering two possible solutions:
> (i) To insert a "_data" component reference after all class object or
> component references during matching.  In those specific cases where a
> _vptr component (eg. the 'hash'field for the select type construct) is
> used, this can be done by changing the _data reference to _vptr and
> adding the hash field reference.

Due to the experiences with scalar polymorphism, my spontaneous
reaction would be that your first option might not be such a good idea
(but I might be wrong - I have not managed to have a deeper look into
your patch yet).


> (ii) Introduce a new type of reference, REF_CLASS_COMPONENT with a
> ref->type ENUM that includes _data, _vptr, size etc. the expansion of
> the reference can then wait until translation; especially in
> gfc_conv_expr and its like.  In the places where this needs to be
> changed, such as in resolving select type, the enum value can be
> changed - that's all!.  This new type of reference, should have a
> typespec corresponding to the _data type, an array spec and a the
> _vptr typespec.

This definitely sounds a bit cleaner.



> In both cases, objects containing class components will be dealt with
> as a matter of course.

Ok. I think it's fine to start with a patch that does not have all the
functionality yet.


Cheers,
Janus