[Patch, Fortran] OOP: merging fortran-dev to trunk?

[Paul Richard Thomas]

Dear All,

I think that we should merge fortran-dev into trunk, for the reasons
that Janus gives.

As said elsewhere, documentation is all important.

Yours truly needs to return to what he always promised to do -
whole-file and memory leaks :-)

Cheers

Paul

On Mon, Nov 30, 2009 at 3:32 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> Hi all,
>
> I would like to discuss here the current state of the OOP features in
> gfortran. As you know, Paul and I have started some time ago to attack
> F03 object oriented features (CLASS, polymorphism, ...). A lot of this
> work has gone into trunk already, where simple polymorphism is working
> but many problems persist. For an overview see
> http://gcc.gnu.org/wiki/OOP.
>
> On top of the basic features which are on trunk, we have been working
> on the more advanced stuff (including an improved internal
> representation) on the fortran-dev branch. The stuff which is on the
> branch now (i.e. mainly EXTENDS_TYPE_OF and SELECT TYPE with CLASS IS)
> has been lying there for quite some time and has received a good
> amount of testing (many thanks to Salvatore and Damian, who were the
> main beta testers and did a great job). I would say the fortran-dev
> branch can be regarded as rather stable (e.g. it nicely compiles
> Salvatore's huge PSBLAS library, which makes heavy use of the new
> features).
>
> Furthermore, Paul has been working very hard on an improved
> representation of polymorphic type-bound procedures (for which he uses
> procedure pointer components in the class container), but
> unfortunately this is not stable enough yet and has not been committed
> to the fortran-dev branch.
>
> I have been discussing quite a bit with Paul and Tobias on how to
> proceed. It's a bit of a nasty situation, since we do have *some* OOP
> in 4.5, but for sure it won't be perfect. [One of the most tricky
> aspects is that there are situations where compilation goes through
> fine, but stuff fails at runtime (cf. PR41829). These issues are the
> same on the trunk and fortran-dev.]
>
> My proposal would be to merge the current state of fortran-dev to the
> trunk now, and leave the advanced TBP stuff that Paul is working on
> for 4.6. As I said, the features on the branch can be considered to be
> rather stable (the more experimental stuff has not been committed
> yet), and most of it is rather low-risk wrt regressions, since it is
> hidden behind BT_CLASS guards.
>
> I am aware that we're in late stage 3, and that this is not a trivial
> patch (the diff between fortran-dev and trunk that I'm attaching is
> about 70k, including test cases). So, we should discuss whether we
> want this or not. From my point of view, the benefits outweigh the
> risks, but of course we need to decide this as a community.
>
> Please let me hear your opinions.
>
> Cheers,
> Janus
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy