Re: Inheritance of gfc_symbol / gfc_component

[Daniel Kraft <d at domob dot eu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I know I've been inactive a very long time (because of lots of other
things I had/have to do), but reading this by chance, I'm still going
to comment.

On 16/08/12 11:11, Janus Weil wrote:
> 
> One of the first things that comes to my mind, when thinking in 
> this direction, is that the structs 'gfc_component' and 
> 'gfc_symbol' have a lot in common (name, ts, attr, as, just to
> name a few), so that one could think about having gfc_symbol
> inherit from gfc_component (in Fortran this would be called "type 
> extension", but I think the correct C++ term is "inheritance"). 
> There are a couple of routines in the front end which basically
> act the same way on components and symbols and which could be
> unified with such an approach (by receiving a pointer, which can
> either point to a gfc_symbol or a gfc_component). Examples: 
> gfc_copy_formal_args, gfc_expr_replace_symbols, 
> resolve_procedure_interface.

I don't know what others here think about using C++ (I remember that
some gfortraners weren't fluent in C++ when the C++ branch was first
discussed), but I personally use C++ over C in my projects and believe
this could really help.

While I don't think big rewrites just for the sake of using C++ are
the way to go, I'm in favour of applying useful features where it
makes sense -- as in this patch for instance.

> Attached you find a very short and simple patch, which implements 
> the trivial part of this inheritance approach: It makes gfc_symbol 
> inherit from gfc_component, and removes those 7 members from 
> gfc_symbol, which are literally equivalent in both structs. (The 
> patch compiles cleanly, but is not regtested.)
> 
> In addition to these 7 'common' members, there are three more 
> members which are more-or-less equivalent, but named differently:
> * 'loc' vs 'declared at' * 'initializer' vs 'value' * 'next' vs 
> 'components' These could be replaced by purely mechanical efforts.
> 
> This leaves only two members of gfc_component, which are not
> shared by gfc_symbol: * norestrict_decl * tb
> 
> In the current simple form of the patch, these would slightly blow 
> up gfc_symbol (being unused there). An alternative could be to set 
> up a base struct, from which both gfc_component and gfc_symbol 
> would inherit.

I would be in favour of the common base class approach, because it is
much cleaner.  It not only doesn't introduce the useless two members
to gfc_symbol (which might later confuse people trying to find out
what they mean!), but if you did the conversion as you suggest, this
would also mean that all gfc_symbol's are "considered to be"
gfc_components as well (and accepted by routines operating on
gfc_components, even if they are really meant only for components) --
which is not what it should be in my opinion, since gfc_symbol and
gfc_component are similar but distinct concepts.

Using a common base class keeps gfc_symbol and gfc_component as
different where they should be, but allows to share members and also
to combine routines that are really meant to work on both -- those
would then have to be changed to accept a pointer to the base class,
as an "explicit action" confirming that they really should accept both
classes.

Yours,
Daniel

PS: I haven't looked at the patch (only the explanation), but as
written above, I'd also prefer to implement the common base class
approach over the described "trivial" version.

- -- 
http://www.domob.eu/
OpenPGP: 3BA2 3DDB 7758 F010 BDAB 0DCF 527E 79BA A3B5 3998
- --
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQLMBeAAoJEFJ+ebqjtTmYyUcQAJLhR+OSShzz1tHt5zyz5zB9
J6XBiqlfPTGiWU/Gq1aVvphoWZixKKHAz9iTqr5j0cHhgSJmh3PMhWN+MCrnvFxg
JpLgsVi0MGgnqMoFuG/P+Y6ZtrPw6aM37Lo/ECcGbBa8UFHDzK/KJrfEBYUnkeYu
rgcfoOjf0d6kyFgLFkg/YFPPZajvPwLvWjz0cc0Ve+u1q3YyQ29zXvZxZXZRl6tF
BhPTVHHwsCELOEJNG9LmdrgNLvtmxx6qhZRxCE30PuE/qkBPlEjOZC90iz3U1jLx
mHE0GzEeiGKkzytCjJ2cbmeDnWJIKBByQ4JBkoezPT5uU+35eMObhsAs+x60KJM9
kITq6TnEFFF2KLdnR/1hrDy5zzd2FxYyM5yfM7S87SIRAYBIwGnxIDoWL38uZfmU
epmNUrVflCq5UvOJEiyz0obfFIvV8aYJDyvzripXPO/qrk57C67hrVRai/WuY42T
RKt1T/mdq5aa1lJUEfraktOO0VSEycGHXV+KG21PEeqsxPB47pRTH35OY31+Ffd6
w8RA47ee//kaC2c+WpzqwKcS2LHKtvDK4YVTUSzROsyFXZpjM2O4gPJ8RD0rLcB/
Z7GYoFe09BmC071Mi+jo0VdwM2oI9IH9TuWO4p4yqGH6hRUVZ+hpNO8JT9xXyg2J
91v5TwNRc2mUbHXq7KSq
=z4uJ
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature