Re: Inheritance of gfc_symbol / gfc_component

[Daniel Kraft <d at domob dot eu>]

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

Hi!

On 16/08/12 13:00, Janus Weil wrote:
>> 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.
> 
> nice to hear from you after such a long time, and thanks for your
> comments.
> 
> Btw, in case you're interested to return to gfortran: The 
> implementation of FINAL is becoming acute again right now (which,
> I believe, used to be an old love of yours). See Tobias' recent
> patch: http://gcc.gnu.org/ml/fortran/2012-08/msg00057.html

I'm right now going off on holidays, but I recently finished my
Master's degree and will probably start on a PhD position soon --
maybe with October.  Maybe I'll have the opportunity then to use
Fortran (partially at least) and also get back to gfortran from time
to time ... we'll see. :)

>>> 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.
> 
> Attached is a new version of the patch, which implements a 
> "gfc_base_symbol" as an ancestor for gfc_component and gfc_symbol.
> For now it only has the seven basic members, which have equal
> names.
> 
> On top of this, I think also loc/declared_at and initializer/value 
> should be put into the base type (in a mechanical follow-up
> patch), since they're really equivalent.
> 
> Does anyone want to OK this patch already, or should I first
> implement some of the applications of the new struct?

As written before, I like this version much better.  The patch is of
course really "trivial" and looks good to me, but I think you should
wait what others think about this plan in general -- and maybe it
would also be a good idea to already add some more things.  So no real
ok from me.

Yours,
Daniel

- -- 
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/

iQIcBAEBAgAGBQJQLOTVAAoJEFJ+ebqjtTmY+/gQAI+J3ko0sFNacVlbPyzZeDC8
WACCV7N5Cfr9nW9NVfdC4vlgfQS4q1YV8xHeBSY/QgW1zVW10InzOAIwYDPWpDu5
cXaKkDLen3kZJnJDTbmPCv61ob4eoK8D/j7ZoS4+83mWSWSTNKg6bU0B3f0bXi6v
T7p3HYzztL8S/ooqNyADZeLLdFj3iTYY4HCRXNCPV1rtMuUfbQmDA/CkDg3+8vLO
a3nw5YcCciFK+nuLJ5WwmXtvnt5XG1F+j/xG1lW/ZHdfMhBxuY4mirDuROhSukJ6
ijuZuJC0M2EdJR+clB8W/bDIZJ5vRa7QhzozT2O6pIdrzTxAsuCEpGIzqkDUZ3T9
In3tgqgOc3W307Qcsqnd9OY8kkrSTU6t9mkk9rE+lqlUbrA/YPH3/oHwNRVwj/bX
5HHOa2HPdqjE3q/4iiSxgbEMcXuwWHsr6gPrV9zlHpi+N6yCiBM7gOe4wpjR33FC
MOIWRsOPjbvFo8fc3zXpT6q8PL7JltgtwxlUMFINeZDoAvEkrxQCHVmXFdpQ7dRO
Czv6hxkETIsxD872v1Mmn0lteBVge+JS7qc2mGbn0vJWt4fBe+iGoI5HCjVxM95v
K3UvwnKlw4dtQmCAE0M/tHjFPRWo0sbUws6yI4Zp7+T0MHJYk7GJbAPfdZogGUYu
0AZkWQbr2sT19sfYd9Ln
=pbva
-----END PGP SIGNATURE-----

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