Re: Separation of API and implementation

On Tue, 14 Aug 2007 14:32:28 -0000, hforco2@xxxxxxxxxxxxxx wrote:

But often hierarchies aren't not really parallel. Either X or Y could be
designed class-wide. Then you dispatch along the opposite axis and no
second dispatch (poorly emulated by a cast in your example) is needed.

Can you give an example of this - I don't fully understand what you
mean by 'class-wide'?

Class-wide = same for all class.

class T = the set of all concrete types derived from T, possibly including
T itself.

When foo is class-wide (in one of its arguments) its implementation need
not to know the concrete type of.

Consider X1, X2, X3 ... derived from X and Y1, Y2, ... derived from Y. foo
is defined for all possible combinations of Xi, Yj. Now there exist four
variants:

1. Full multiple dispatch is when for each combination there exists a
distinct implementation of foo. Java cannot this.

2. Single dispatch in X. foo has a distinct implementation for each Xi. For
Yj these implementations stay same = foo is dispatching in X and class-wide
in Y. Java can this, if X is the first, hidden argument and Y is the second
explicit argument (by reference).

3. Single dispatch in Y, class-wide in X. This is reverse to 2.

4. No dispatch, foo is class-wide in both arguments. This is so-called free
function, I don't remember if Java can this. But that is no matter.

Now, what you want is a parallel hierarchy. That is the case 1 with the
constraint that foo has a distinct implementation for each Xi, Yj, where
i=j. Otherwise, there is "no" implementation in the sense that either an
exception is propagated or the compiler at compile-time detects invalid
combinations and marks them as illegal.

You cannot have this in Java due to numerous limitations of. So you have to
reduce it to either 2 or 3, or else emulate double dispatch in some quite
tricky way.

There is an alternative to kill Y as a class and handle each Yj
individually. This is the essence of H.S. proposal.

In what sense is it a bad design?

Because it bends the language beyond its capacities. Java was not designed
for parallel hierarchies. As I said before, it is a hard problem and people
stumble upon it all the time. Canonic parallel hierarchy examples are:

Thing + Handle_To_A_Thing;
Thing + Key_Of_A_Thing + Container_Of_Things;
Thing + Factory_Parameter_Of;
Element + Vector + Matrix.

The question is whether you really need a parallel hierarchy in your
concrete case.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Question about OO programming in Ada
    ... >> Dispatch table is a property of a dispatching subroutine. ... >of that class contains a pointer to this single dispatch table. ... This is exaclty what I meant by claiming that it is not a class-wide ...
    (comp.lang.ada)
  • Re: macros
    ... (:method ((foo foo) ... (baz baz)) ... I don't see any namespace related anything in that. ... manually managed dispatch tables and plenty of other migraine-inducers ...
    (comp.lang.lisp)
  • Re: Is Double Dispatch really object-oriented?
    ... Compile error, in a language that supports MD properly => ... No dispatch ever fails ... Do you seriously claim that you can test Foo having just one B? ...
    (comp.object)
  • Re: tagged record child: override constructor?
    ... It is error-prone because of enforced re-dispatch One ... should explicitly specify T::Fooreferring member functions within a ... procedure Foo is ... -- This does not dispatch! ...
    (comp.lang.ada)
  • Re: Is Double Dispatch really object-oriented?
    ... No dispatch ever fails ... Also if polymorphism is an essential part of OO, ... Do you seriously claim that you can test Foo having just one B? ... The contract of A is the only way. ...
    (comp.object)