Re: [RFC] polymorphic arrays

[Daniel Kraft <d at domob dot eu>]

Janus Weil wrote:
> Hi Daniel,
>
> thanks for your comments!
>
> > > Now the question is what to do for polymorphic arrays, i.e. CLASS
> > > variables with the DIMENSION attribute. Basically I see two
> > > possibilities:
> > > 1) Use the class container also for polymorphic arrays, and have the
> > > "$data" field point to an array descriptor.
> > > 2) Extend the array descriptor to include some "$vptr" field, which
> > > would determine the dynamic type of the array, and use this instead of
> > > a class container.

> > To me it seems that #1 is the "natural" approach given what we currently do.
> >  While going with #2 seems to be more light-weight and "better" to me for
> > arrays, it will both introduce a somewhat distinct implementation for
> > polymorphic scalars and arrays and will also not work with the approach of
> > doing everything (or mostly everyting?) at the front-end level -- at least
> > it seems thus to me.
> >
> > I do not know what to recommend, but if you go for #2, I would think about a
> > way to nicely use a "similar" technique also for polymorphic scalars if
> > possible.
>
> Of course it would be nice to treat all the cases in one consistent
> framework. If one decides for #2 as the superior approach, then one
> could in principle unify the treatment of polymorphic scalars + arrays
> by using an array descriptor also for scalar classes (basically array
> descriptors and class containers are similar concepts anyway). This
> would introduce a bit of memory overhead, since the array descriptor
> includes fields which are not needed for scalars. However, one would
> gain in consistency.

Yes, that's a possibility.  And it sounds nice to me in that it actually 
contributes more to a unification of concepts, namely between array 
descriptors and class containers.  I don't think that the memory 
overhead will be a real problem, as using OOP stuff will by itself 
always introduce some overhead (think of more indirection because of 
virtual functions, the vtab itself and other such stuff) -- and the 
argument that seems to come up with respect to that is that this 
overhead does not matter compared to the benefit OOP brings in certain 
situations.  And I think especially memory consumption is not the most 
pressing issue in this respect -- but that's only my impression, and of 
course we should try to keep things as efficient as reasonably possible.

> Btw, another asymptotic aim for our OOP implementation could be to
> have consistency/interoperability with C++ classes. However, I
> presently have too little knowledge of the implementation of
> poylmorphism in g++ to say anything more concrete about this topic at
> this point (any pointers in this direction are welcome, though).

That sounds like a very interesting goal; however, I'm not really sure 
it is a very achievable one -- thinking of multiple inheritance, virtual 
inheritance and probably also a lot of small differences between OOP in 
C++ and Fortran.  Do you think this would really be useful at a greater 
scale?  BTW, I think that Java does something like it...  Although I 
never really used gcc's Java (or Java at all for already some years).

Cheers,
Daniel

--
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri