(j3.2006) Chaining type-bound procedure references

[Damian Rouson]

________________________________
Damian Rouson, Ph.D., P.E.
Founder & President, Sourcery, Inc.
510-600-2992 (mobile)
http://www.sourceryinstitute.org
http://rouson.youcanbook.me





On Apr 30, 2014, at 4:37 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
>>>> 
> 
> INTERFACE method2
>   MODULE PROCEDURE do_method2_on_something
> END INTERFACE
> 
> FUNCTION do_method2_on_something(something) RESULT(r)
> declare the result
> CLASS(someobject) something
> r = something%method2
> END FUNCTION
> 
> val = method2(obj%method1())

This is at least a better alternative for the user-defined operator case.  When I want

u%x()%x()

I would instead end up with

d_dx(u%x())

where I?m calling the same procedure twice but one of the times I?m doing it through a generic interface.  I wouldn?t be completely thrilled because someone reading it for the first time might not realize I?m applying the same function twice, but at least it?s compact and the reader can figure out quickly what?s going on once they realize that d_x is just a generic interface for x(). This raises problem, however, that the type-bound procedure x() can be inherited while the generic interface d_dx has to be repeated in every descendent type, which feels really clunky from the standpoint of OOP. It would be a step backwards to Fortran 90-style programming from my perspective.
 

> I don't think we can do this without opening the floodgates to
>   func(...)%component
> which we decided against doing long ago.

I agree this is the obvious next step.  It?s definitely where my mind has gone in the past, but I ultimately decided that it would be wasteful to compute a whole array function result if all I really want is some subset of the elements so I think there are good arguments for allowing Tom?s original suggestion but denying this obvious next step.

Damian