This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran] OOP cleanup
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 May 2010 06:38:18 +0200
- Subject: Re: [Patch, Fortran] OOP cleanup
- References: <AANLkTilfZmFj6IkUwU4knbBkEm9abkkHg3pZPMdykuJN@mail.gmail.com>
Dear Janus,
> Comments? Suggestions? Ok for trunk?
OK for trunk, subject to a few remarks.
(i) The copyright years in class.c need only be 2009 and 2010;
(ii) Please add a comment to the top of class.c to say that it
contains the front end functions needed to service OOP. We should
expand this later to include some documentation of the representation,
as in trans-array.c;
(iii) I would also shift to class.c resolve_typebound_function and
resolve_typebound_subroutine since they implement dynamic dispatch;
and
(iv) You might contemplate the value of moving resolve_compcall and
its dependencies as well. If you do this, add Daniel Kraft to the
guilty parties :-)
>
> [Btw, after this re-shuffling of the polymorphism code I plan to do
> some more cleanup. E.g. Tobias suggested to introduce encapsulating
> routines for accessing attributes of class variables. This is very
> much complicated by the presence of the class containers. It is
> another thing which is scattered throughout the code, and depends
> strongly on the internal representation of class variables. This point
> surely could use some abstraction.]
Yes, I agree. I thought to use macros in gfortran.h, such as
CLASS_DATA(sym) to provide the data component and so on. I got as far
as writing the macro and applying it in one place to check all was
well but lost it in trying to fix the fix PR43945 (which I still have
not figured out BTW).
Thanks for the patch
Paul