Re: Implementing JAVA interfaces in FORTRAN 20xx

On 26 août, 01:01, e p chandler <e...@xxxxxxxx> wrote:
On Aug 25, 10:31 am, fj <francois.j...@xxxxxxx> wrote:



On 25 août, 10:21, Reinhold Bader <Ba...@xxxxxx> wrote:

fj schrieb:

I don't want to use the inheritance here (because F2003 supports only
a single inheritance). For instance, I want to be able to declare
something like that :

type, extends(roottype), implements(ordered_type) :: mytype

Well, your initial example did not indicate this. In any case, this is a
form of limited multiple inheritance which indeed is not supported explicitly.
You can however have a type definition

type, extends(ordered_type) :: mytype
type(roottype) :: r
:
contains
: ! map needed TBPs of roottype, as well as deferred methods of ordered_type
end type

which will do the equivalent with only a little additional wrapper code.
If you need to override roottype methods anyway, the needed programming effort
is in fact the same.

[...]

Regards

But this is a pity because extending an abstract type associated with
predefined routine signatures is much easier than extending a actual
type.

And because this is much easier, it is possible in JAVA to extends
(more precisely to implement) as many abstract types (JAVA interfaces)
as necessary when it is possible to extend only a unique actual type
(single inheritance).

Please explain how this does any real good in Fortran at all. As I
understand it, you can not pass an array of integers to a routine
which expects an array of elements, each of which is of derived type,
each of which consists only of an integer.

- e

OK : my example (quicksort) was not the best choice. I agree with
you : an array of integers cannot match an array of derived types.
This is also true in JAVA as well (but in JAVA one also disposes of
the class Integer in parallel to the scalar int).

In fact I just wanted to show that extending abstract types could be
an interesting feature for FORTRAN. This is not really inheritance
because you do not inherit neither data (the abstract type is empty)
nor routines (the abstract type is associated to abstract routines :
only the signatures are interesting).

Let us assume that you have already defined a derived type "t1"
extending "rt1" and a derived type "t2" extending "rt2".

But t1 and t2 have to follow a same behavior which does not concern
neither rt1 nor rt2. Then it becomes possible to create routines
receiving as argument an object having just to follow the expected
behavior. The behavior in my example was the operator <= : any object
providing this operator becomes a valid argument matching the abstract
type.

This is often the case in scientific modeling : for instance a "air"
mesh and a "concrete" mesh have practically no common fields. But one
might need to compute the enthalpy and the density for both ... You
can say that one just need to extend a common type binded to enthalpy
and density routines. Yes but this is not possible today if the "air"
mesh already extends a "fluid" mesh and the concrete mesh already
extends a "wall" mesh.

Of course you could say that one can add in the "fluid" and "wall"
mesh routines computing the enthalpy and the density. That's true but
you do the job twice which is not very useful if other extended fluid
and wall objects to not need to compute enthalpy and density.

To define a behavior, one just need to create an abstract type "at"
binded to the operator <=. The type "t1" and "t2" have to extend "at"
in some way. I proposed the syntax :

type,extend(rt1),implements(at) :: rt1

But a syntax like

type,extend(rt1,at) :: rt1

could be adopted with the limitation that only one type in the list
"extends" could be non abstract.

It will even become possible to build up an array of objects matching
that abstract type using the F2003 class keyword :
class(ab),ALLOCATABLE :: v(:)

As summary, extending an abstract type allows a kind of simplified
multiple inheritance without most of the difficulties associated to
general multiple inheritance.
.

Relevant Pages

  • Re: COBOL and Java Relative Perceived Power
    ... that doesn't,of itself, violate encapsulation. ... because both the current override and the super class are ... inheritance, I don't think it is important enough to make me NOT inherit, ... It is also safe to use inheritance when extending classes ...
    (comp.lang.cobol)
  • Re: COBOL and Java Relative Perceived Power
    ... Extending it makes its methods ... "visible" but that doesn't,of itself, violate encapsulation. ... Overriding a super class method in a subordinate class doesn't ... I agree that inheritance can be overused, ...
    (comp.lang.cobol)
  • Re: Newbie question
    ... > inheritance unless you really need it (or, ... I do avoid extending GUI classes for minor dialogs and the ... it's also apparent that a GUI builder tool is being ...
    (comp.lang.java.gui)
  • Re: Implementing JAVA interfaces in FORTRAN 20xx
    ... a single inheritance). ... form of limited multiple inheritance which indeed is not supported explicitly. ... predefined routine signatures is much easier than extending a actual ... as many abstract types (JAVA interfaces) ...
    (comp.lang.fortran)
  • Re: Implementing JAVA interfaces in FORTRAN 20xx
    ... a single inheritance). ... form of limited multiple inheritance which indeed is not supported explicitly. ... predefined routine signatures is much easier than extending a actual ... which expects an array of elements, each of which is of derived type, ...
    (comp.lang.fortran)