[RFC] polymorphic arrays

[Daniel Kraft]

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