> Yes, it's a technique I call "hollow classes".  It pretends to be OOP,
> but nothing but place holders for the algebraic properties of the data
> type is really defined by the parent classes.  This is similar to what
> Haskell does (it even uses the word CLASS as a keyword), which
> is definitely *not* an OOP language.
The "Multipliable" class I had in my example is what I would call a
"Mix-in" class. In C++ it would be an abstract base class (ie you can't
instantiate it), and in java it would be an interface. This class
defines the algebraic properties  of the data type in exactly the same
way as your suggestion that a separate entity could be used to  do this
in the parameterized polymorphic case. In the example, it would
effectively state that a Multipliable class must define operator *. I
actually see no difference between the two approaches, since no
implementation is inherited from Multipliable in either case, only
interface.

> This is one of the problems with using OOP to emulate parametric
> polymorphism.
I'm not sure there is any "emulation" happening. The inheritance
relationship is quite natural in this case. An object inherits the
property of being "Multipliable".

> It would be better to be able to define the property
> "multipliable" independent of any class heirarchy, then explicitly
> mention that property in the interface specification for the procedure's
> argument.
Really this is no different to what you do in java:

interface Multipliable {
...
}

RealArray implements Multipliable {
...
}

It's just a symantic difference to what you would do in C++, more
elegant, but effectively the same.

> Among other things, this means that you don't need your
> types heirarchically related to one another - which is usually difficult
> and non-intuitive to achieve anyway - and is one of the factors which
> restricts class heirarchies from being very modular.
Don't really agree. I think this is one case where inheritance can be
made very effective. A "mix-in" class provides no implementation, so it
can be made very modular.
And classes which inherit from "Multipliable", or implement the
interface in the java case, do not have to be related in any other way.

RealArray implements Multipliable {}
Elephant implements Multipliable {}

The only advantage I see of parametric polymorphism is performance,
since everything is worked out at compile time.

Drew

================================
  Dr. Drew McCormack
  Department of Theoretical Chemistry
  Science Faculty
  Free University Amsterdam
  De Boelelaan 1083
  1081 HV Amsterdam
  The Netherlands

  Email :: [log in to unmask]
  Tel.     :: +31 20 44 47623
  Fax      :: +31 20 44 47629