Re: [Patch, fortran] Preliminary patch for derived type extension

[Daniel Kraft <d at domob dot eu>]

Paul Richard Thomas wrote:
> > It's maybe not really my taste to make the super-type just the first
> > component of the derived type (if attr.extended is on).  I'd probably
> > include another pointer in the derived type structure itself (besides
> > "components"), say, "super"; but that's probably a symptom of my usual hang
> > for overpowered designing...  Another idea would be to define a
> > macro/function to access the super-type.  But both of those are probably not
> > really necessary, just go ahead :)
>
> The whole point of derived type extension is that the parent is NOT a
> super type.  It's components are part of the extension.  It was a
> whole lot easier to include the parent derived type rather than its
> extension because existing code to find components could be used.

Hm, probably we missed each other.  I think it's the right way to 
include an instance of the extended type as component, of course (as 
this truely makes things easier I suppose) and that's also what I'd do.

I was just remarking that in case one wants to access the extended type 
(for whatever), it would be nicer to write

gfc_get_super_type(extension_type_symbol)

rather than

extension_type_symbol->components->ts.derived (or so)

It just seems cleaner to me; or adding a new pointer to the structure 
pointing to the same derived type:

extension_type_symbol->extended_type

That's what I tried to express above ;)

> > !   if (extended && !sym->components)
> > !     {
> > !       gfc_component *p;
> > !       gfc_symtree *st;
> >
> > I've not looked thoroughly at the code, but why is the this check for
> > !sym->components?  When could there already be components?  Why don't we
> > need to add the super-type in that case?  Quickly and without knowing the
> > details, I'd say an assertion would be better?
>
> Believe it or not, this code to build the derived type seems to be
> visited more than once.  I will check this because this is a fault, if
> so.  The check came about to stop the parent derived type being added
> more than once.  As I say, I will check this thoroughly.

Ok, I didn't think about that one.  That's right and I experienced the 
same "problem" (or a similar one) during the finalization patch, too.

> > I'll think about type-bound procedures a bit and if I've additional comments
> > regarding the future implementation of those, I'll post them later.
>
> I have some ideas about how to do this - I'll try to get them to you tonight.

Thanks!  I'm at the moment studying the standard and thinking about how 
I'd do it, myself.  I maybe start writing some tests, but for the code 
I'll wait for your ideas, then.

Daniel

--
Done:     Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
Underway: Cav-Dwa-Law-Fem
To go:    Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou