(j3.2006) Chaining type-bound procedure references

[Tom Clune]

Malcolm,

On Apr 30, 2014, at 7:37 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:

> <<<
> On several occasions, and today in particular, I have encountered the situation 
> where it would be clearer (and definitely easier) to implement an algorithm in 
> the following fashion:
> 
> val = obj % method1() % method2()
> 
> Here method1() returns some object, and method2() is bound to class of that 
> object.   And I realize of course that the language does not (currently) permit 
> anything like this.
>>>> 
> 
> 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())
> 
> Yes this "pollutes" the namespace slightly, and you *might* need a helper 
> function (though the way we've done object orientation you can have a single 
> function that will be both a normal function and type-bound) but the invocation 
> is simple.


Thanks for your suggestion, and in fact I am using that approach in some cases.

The namespace pollution is a serious issue, but even worse from my pov is the requirement to modify an otherwise well-constructed class.

My immediate motivation is for manipulating iterators over containers (ala C++ STL).   The value of an iterator goes up immensely if the client can readily invoke methods on the referenced contained object.     I have created a preprocessor-based template that allows me to readily create certain types of containers and associated iterators for rather arbitrary contained types.   Unfortunately, clients of these iterators must "dereference" the iterator frequently to access the referenced object and then invoke the methods on the referenced object.  Possibly I'm being a bit too zealous about encapsulation - if I make the internal pointer public, my immediate issue is solved.   But there are other scenarios where encapsulation would be essential.

The approach you (Malcolm) suggest above is good in that it prevents the need to declare and use an intermediate variable, but at the cost of creating a (possibly large) set of interface declarations.   It is inappropriate for the class of the contained objects to be forced to undergo such a modification merely so that it can be used with containers/iterators.    (Inversion of responsibility.)   The alternatives are for the container template or the client to create said wrappers.  The former would be well beyond the simple preprocessor approach I am using, and the latter is a heavy burden for the clients of my container classes.

All of this is handled quite elegantly in C++ iterators by simply providing an operator (dereference operator in this case) that allows iterators to look like pointers in terms of accessing methods on the contained object.   At the same time, proper encapsulation is maintained -- one cannot make the internal pointer point to something else through the public interfaces.


> 
> <<<
> I can guess that there are some inherent ambiguities that make my syntax above 
> non starters, though I cannot readily think of what the are.
>>>> 
> 
> I don't think we can do this without opening the floodgates to
>   func(...)%component
> which we decided against doing long ago.

I realize that the decision was wade long ago, but it is not immediately obvious to me why "floodgate" is the appropriate metaphor.   Even if there are some terrible complications in the example you cite, would they still apply if we had an operator (e.g. "->") that made the situation explicit.   Is the concern that anonymous objects would be a headache to implement, or is it that ensuring the consistency of the standard would be a nightmare?   I'm not competent to comment on either with any authority, but the associate block approach provided by Reinhold seems to suggest that the gotchas would be manageable on both fronts.


> 
> And it does seem like a pretty big feature that does little more than provide 
> alternative syntax for something we can do easily already.

I disagree about the latter. (And was hoping that the former was not true.)   I could just as easily make the same comment that invoking type-bound procedures using obj%method(?) instead of method(obj,?) is alternative syntax for something we can do easily already.   The clarity of the new syntax is powerful.    Or,  if I've misunderstood something in the standard and the two expressions are not always equivalent, then the same argument would apply to your solution above.

Cheers,

- Tom




> 
> Cheers,
> -- 
> ................................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 					<Thomas.L.Clune at nasa.gov>
CISTO	Code 606.0
NASA GSFC								301-286-4635
MS 610.8 B33-C128
Greenbelt, MD 20771






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140501/24967d55/attachment-0001.html