Daniel Grimwood wrote:
> It should be forbidden, since it would result in a name clash.
I disagree. In most situations I can think of you would like to use multiple
inheritance in such a situation and the answer is "there should be one shared
grandparent component. But I am sure some will argue that they need to have
two different components...
> Does the point have colour information or does the colour have point
> information?
OK, OK, I worded it too harsh. It is imaginable that if you are dealing
primarily with colors you would add point information, but in "scientific"
applications it will usually be the points and their coordinates that are the
central object of abstraction, and you would add color just to, for example,
plot the things during visualization.
> type :: colour_point
> class(colour) :: rgb
> class(point) :: position
> end type
> which is practically Fortran 90.
No, because this can be "extended" in both directions with the use of the
polymorphic pointers.
> Of course we would still primarily use embedding,
> but there are several cases we have where multiple parents would be very
> beneficial.
Daniel, there is no need to convince me. I am perfectly on your side. The
decisions on what was to go into OOP in Fortran were made long before I
started work on it...Why did you not comment on F2003 during public comment
period and complain about it?
In fact, I again include a long rant (it is a rant!) I sent to this list a
while ago complaining about lack of multiple inheritance:
Hello,
This is a rant on an important subject for those interested in OOP
features in F2x. It asks for opinions mostly.
In F2x we only have single inheritance. This was decided a long time
ago. In cases where multiple inheritance might be useful in some other
languages, one must use embedding instead, meaning adding a (possibly
polymorphic) component to the type declaration, instead of type
extension. I have been trying to think of reasonable guidelines on when
to use inheritance versus embedding but am not doing too well. I thus
ask for opinions/references etc.
Here is an example. There are 4 main types in a given type hierarchy:
1. Point_Pattern, representing a static collection of points (with
specific boundary conditions, almost always periodic) equipped with some
tools to find near neighbours and localize points. This should probably
have a method to Synchronize all points to the same point in "time". The
points are typically the centroids of certain objects, such as
particles/molecules etc.
2. Then we have a Dynamic_Point_Pattern, where the points also have
velocities and may be moved around while maintaining the spatial
localization database (in this case a simple grid of bins/cells).
3 and 4. Finally, we have parallel versions of both type, which
represent (domain) partitioned collections of points,
Parallel_Point_Pattern and Paralell_Dynamic_Point_Pattern.
The question is, how to organize these types well into a type
hierarchy/structure. For example, should Dynamic_Point_Pattern extend
Point_Pattern or embed a polymorphic pointer to an object of type
Point_Pattern?
One possible F2x organization is something like:
TYPE Point_Pattern
CONTAINS
PROCEDURE, PASS :: Synchronize=>SynchronizePP ! This procedure does
nothing
END TYPE
TYPE, EXTENDS(Point_Pattern) :: Dynamic_Point_Pattern
CONTAINS
PROCEDURE :: Synchronize=>SynchronizeDPP
END TYPE
Now we have the parallel versions:
TYPE :: Parallel_Point_Pattern
CLASS(Point_Pattern), ALLOCATABLE :: pp
! In initializer allocate this to be of TYPE(Point_Pattern) if not
already allocated
END TYPE
TYPE, EXTENDS(Parallel_Point_Pattern) :: Parallel_Dynamic_Point_Pattern
! In initializer allocate pp to be of TYPE(Dynamic_Point_Pattern)
ENDTYPE
Hopefully the questions here are evident. The choice of when to inherit
and when to embed is not clear, or is it? With the present choice,
Parallel_Point_Pattern can end up having an embedded point pattern that
is dynamic, which it is obviously not equipped to do. But if I extend
the type Point_Pattern to Parallel_Point_Pattern, then the
Parallel_Dynamic_Point_Pattern has a problem of how it gets to a
Dynamic_Point_Pattern. It seems that Parallel_Dynamic_Point_Pattern
should extend (i.e. use inheritance) both Dynamic_Point_Pattern and
Parallel_Point_Pattern, and this is what cannot be done directly in F2x
(possibly for good reasons).
Things are of course complicated further because one needs to further
use these to construct things like a type representing a collection of
hard particles, which need the point pattern in order to implement
neighbourhood searches, but need to also add additional components.
Any ideas on how to resolve things like this would help. Things like
Design Patterns do not seem to be of use here...
Thanks,
Aleksandar
|