Hi,
On Thu, 18 Sep 2003, Aleksandar Donev wrote:
> Problems start appearing when, for example: A extends B which extends C,
> and A extends D which also extends C. Does A have two distinct
> subobjects of type C (we call them grandparent components in F2003, I
> guess), or one?
It should be forbidden, since it would result in a name clash. Note 4.53
of the August draft says "A component or type parameter declared in an
extended type shall not have the same name as any accessible component or
type parameter of its parent type". Can't we apply the same rule between
multiple parents? This could allow multiple parents with minimal change
to the standard.
> You can emulate multiple inheritance by using imbedding:
>
> type point
> real :: x,y
> end type point
> type colour
> integer(3) :: RGB
> end type colour
> type, extends(point) :: colour_point
> class(colour) :: rgb
> end type
>
> In your particular example this is the *correct* thing to do. A colour_point
> is *not* a colour. It is a point which has (contains) colour information.
> Inheritance should be reserved for "is-a" relations only.
Does the point have colour information or does the colour have point
information? An equally valid representation would be
type, extends(colour) :: colour_point
class(point) :: position
end type
The choice is arbitrary, but necessary under single inheritance. (I chose
this example because it's the one in the standard). Perhaps it should
just be
type :: colour_point
class(colour) :: rgb
class(point) :: position
end type
which is practically Fortran 90.
That last example is pretty much our programming style now. We have been
using pseudo type-bound procedures with this style in Fortran 90 for years
via a preprocessor and an implicit "self" dummy variable. The problem we
have is that a lot of routines in our "extended" types are just wrappers
to routines in their embedded types. For example, colour_point%hsv would
call colour_point%rgb%hsv, and colour_point%translate would call
colour_point%position%translate. The end result is a lot of unnecessary
code and maintenance. Of course we would still primarily use embedding,
but there are several cases we have where multiple parents would be very
beneficial.
Regards,
Daniel.
------------------------------------------------------------------------
Dr. Daniel Grimwood Department of Chemistry
Email : [log in to unmask] The University of Western Australia
Phone : +61 8 93808563 35 Stirling Highway
Fax : +61 8 93801005 Crawley WA 6009
|