Re: [OOP] SELECT TYPE with CLASS IS

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Janus,

The patch looks OK to me - apply it to the branch if you have not
already done so.

I too think that 255 ancestors should be quite enough :-)  However,
+  fclass->attr.extension = ts->u.derived->attr.extension + 1;
could do with an error or a warning if the result overflows.

I have now cleared all the obstacles to implementing generic methods;
it turned out to be a bit more cumbersome than anticipated; a
vtab-like object is needed for each generic procedure, which carries
pointers to the specific procedures.  It'll be out in a day or two.

Cheers

Paul

On Mon, Nov 9, 2009 at 9:17 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> Hi all,
>
>> here is an early shot at CLASS IS. As announced before, my
>> implementation uses the library function "is_extension_of" that I
>> introduced with the EXTENDS_TYPE_OF patch and translates the CLASS IS
>> cases into a chain of IF/ELSE IF statements (you can have a look at
>> the dump for the attached test case to see an example of the code it
>> generates). The patch is not quite complete yet, since CLASS IS cases
>> are not being sorted if they're in the wrong order. But apart from
>> this, most things should work already. In particular the following
>> cases:
>>
>> ?* SELECT TYPE statements with only one CLASS IS branch
>> ?* those cases where the CLASS IS labels are not extensions of each other, or
>> ?* cases where the CLASS IS labels are sorted in the right way
>> manually (i.e. extensions before their parents)
>>
>> If anyone wants to try it out or have a look at the patch, that would
>> be great (the patch has to be applied to the fortran-dev branch, btw).
>> I'll try to get the sorting right soon.
>
> the attached version of the patch adds the sorting, and should be able
> to produce the right runtime-behavior for any combination of CLASS IS
> blocks.
>
> My first thought regarding the sorting of the CLASS IS cases was to
> simply go through the list and for any given pair determine if one
> type is an extension of the other. However, this naive plan has some
> problems:
> 1) For each pair, you have to do two operations: Check if A is an
> extension of B. If not, check if B is an extension of A. This check
> would involve stepping through the inheritance tree (which can be
> quite large in extreme cases).
> 2) In this way, you can not find a unique order of the blocks, since
> some of the types may not be related at all.
>
> It just occurred to me a few hours ago that there is a much more
> elegant and efficient way to do the sorting. For this, I took the
> attr.extension bitfield that Paul introduced when he implemented type
> extensions, and expanded it by a few bits, so that it not only
> determines if the type if an extension of another, but instead
> contains a number which describes the "extension level" of the type.
> That is, if you draw an inheritance tree based on a certain base
> class, the "extension level" is simply the level at which a certain
> type is located (the basetype having extension=0, its direct
> descendants having extension=1, etc).
>
> This is a natural generalization of the extension field, since
> extension=0 still means the type is no extension, while extension>0
> means it is. So all the present code which checks the extension field
> still works. For now I chose to make the field 8 bits wide, so that
> inheritance trees with up to 255 levels are possible (the actual
> number of types in the tree can be much larger), which I think is hard
> to exceed with any reasonable application (am I being too naive
> here?).
>
> But most importantly, this "extension level" provides a natural
> ordering scheme: Highest extension levels must always come first in
> the CLASS IS chain, which guarantees that descendants come before
> their parents. For equal extension levels, ordering does not matter.
> And that's it!
>
> Then I just made sure to correctly set the 'extension' field, when
> constructing a derived type, and implemented a simple bubble-sort on
> the singly-linked list of CLASS IS blocks, based on the 'extension'
> field.
>
> I successfully checked the patch for regressions. Do you guys have any
> comments or suggestions, or is it okay if I commit to fortran-dev?
> (Will write a ChangeLog and dejagnuify my test case soonish.)
>
> Cheers,
> Janus
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy