This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] OOP cleanup


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]