[Patch,Fortran] Add polymorphic type support (OOP, RTTI) - merge from Fortran-dev branch

[Paul Richard Thomas]

Dear Daniel,

Thanks for the indeed unasked for review :-)

> Your dynamic dispatch is done (if I understood it correctly) by building a
> switch on the vindex which has labels for each subtype of the CLASS'
> declared type and where the then-appropriate procedure is called.  Am I
> right here?

That's correct.

> I'm not sure about what we would expect in that case, but from a C++ point
> of view, one should be allowed to declare a derived-type in a module and use
> it there with CLASS, but the compiled code should also work when passed a
> CLASS object whose actual type is some subtype that was unknown at
> compile-time of the original module.  Would this work?

I am not entirely sure that this would be standard compliant in
fortran.  We have discussed the matter but have not really concluded.
My tilt is that all subtypes should be known at compile time because
they should all be use associated.  In fact, I am reminded that we
need to warn that attempts to define classes in interfaces will not
work at present.

>
> Tobias mentioned a possible rework of the internal structure for 4.6, so I
> guess this is not something really important...  But later on, we could
> instead use a vtable of procedure-pointers for dynamic dispatch; IIRC, you
> even mentioned one some time, didn't you?  Just some thoughts, though.
>

Yes, we should certainly go down that route.  In fact, I thought
through an implementation of vtables last night that I believe will be
rather easily put in place.  I will try and post a description in the
next days.

> +      /* If we have to match a passed class member, force the actual
> +        expression to have the correct type.  */
> +      if (!tbp->n.tb->nopass)
> +       {
> +         if (e->value.compcall.base_object == NULL)
> +           {
> +             e->value.compcall.base_object = gfc_get_expr ();
> +             e->value.compcall.base_object->expr_type = EXPR_VARIABLE;
> +             e->value.compcall.base_object->symtree = e->symtree;
> +             e->value.compcall.base_object->ref = gfc_copy_ref (e->ref);
> +           }
>
> You could replace those four lines generating the base_object by a call to
> extract_compcall_passed_object if you want, but of course you don't save
> much.  I'd still do it, I guess.

Indeed - thanks for pointing that out.

>
> All in all, I think the patch is ok.  But as I've not yet really read the
> other polymorphism patch, I don't feel confident to give a review here (and
> you didn't yet request one, did you?).

See above :-)  Your comments are very welcome though.

>
> Thanks for your and Janus' work here!

Janus was the inspired one who got us moving.  I have been rushing to
keep up with him ever since....

Cheers

Paul