Re: Is Double Dispatch really object-oriented?

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:
On Thu, 19 Oct 2006 11:41:00 GMT, Daniel T. wrote:
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:
On Thu, 19 Oct 2006 02:23:23 GMT, Daniel T. wrote:
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:
Daniel T. wrote:

If 'a' in function is not an A1 and 'b' is not a B1, then the
generic method is called. If 'a' is an A1 and 'b' is not a B1,
then the special A1/BaseB method is called, if 'a' is not an A1
and 'b' is a B1, then the special BaseA/B1 method is called.
What if 'a' is an A1 and 'b' is a B1?

Compile error, in a language that supports MD properly =>
fulfills the requirement No.1:

No dispatch ever fails

Therein lies the rub. One cannot test or analyze A1, B1, A2, B2,
&c. independently of each other, it's all or nothing.

I don't see your point. Should dispatch fail? Would it make things
more testable, if failure happened at run time rather than at
compile time?

No you don't see my point. It doesn't matter if dispatch fails or
the program refuses to compile.

Then I don't see any relevance of the example you presented. As you
said, it neither supports nor refutes your point.

It does support my point. The A1 class cannot be inserted into a test
harness to make sure it does the right thing, because its behavior is
dependent on its environment.

Again, whether MD takes place is *independent* on testability and,
for all, on one's desire. Show me a sorted polymorphic container
without MD. How would you define order on one argument?

Not that it matters but std::set in C++ is such a container.

Do you seriously claim that less<Key> can be defined on one
argument? My challenge is to present a container which elements can
be 1) sorted, 2) of different types. Show how this could be done
without MD on elements comparison.

Do you seriously think the number of arguments is at issue? Now you are
being purposefully dense.

Reductionist understanding is lost and as we have already agreed,
both reductionist and holistic understanding are necessary for
complete understanding.

As I said earlier, it is already lost with dispatch. You cannot
test the class A as a whole, without testing all its instances A1,
A2,..., An, ....

I never said anything above about testing class A, it's an abstract
concept (interface.)

i.e. testing a dynamically polymorphic subprogram is impossible =>
down with SD.

That is obviously wrong.

In MD, it's all or nothing; every possible derivative of A and B
must exist in the system before any of them can be tested in any
way. With SD, we can have just one derivative of either A or B
tested against a mock-up of the other.

Really? Consider this:

class A
{
public :
void Bar () = 0;
};
class B
{
public :
void Foo (A& X) { Bar(); }
};

Do you seriously claim that you can test Foo having just one B?

I seriously claim that I can test Foo by creating a mock A and I will
*know* that B will behave the same way when I hand it any other type of
A. Now compare that to the MD version:

class A { void bar() = 0; }
class B { };

void foo( B& b, A& a ) {
a.Bar();
}

Can I make any guarantees as to how foo(B, A) will behave if passed an
A1, A2, or A3 along with my B? No, because any of those sub-classes
might reimplement foo to do something different.

You said yourself, you are framing this as a reductionist vs
holistic argument, SD being reductionist and MD being holistic.

I never said that SD and MD would take sides. What I said is that
dispatch cannot be reduced otherwise than by considering interfaces
and contracts.

I said:
This is an attempt to frame the argument as Holism vs Reductionism

and you replied:
Yes

You can't get away with such re-visioning when Google groups is
recording every post. I'm now officially done with you.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer have anyone to discuss your doubts with,
nor any ability to discuss them.
.

Relevant Pages

  • Re: Javascript taking over?
    ... stronger typed languages finding more problems during compilation. ... A 'variant' variable can probably hold any value ... dispatch). ... type of dispatch must be done at compile time ...
    (comp.lang.misc)
  • Re: Is DEFCONSTANT broken?
    ... (defconstant foo ...) ... If you compile a file containing defconstant which is used in that file, ... defconstant overcomes the externalizeability problem by externalizing the ...
    (comp.lang.lisp)
  • 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: Whats up with Scheme macros?
    ... which is NOT part of the spec for defmacro: ... might be effectively a bug in the spec since it really ... there is an issue because (foo) is in a context where the definition inline ... But the value of x is needed at compile time, ...
    (comp.lang.lisp)
  • Re: HashMap get/put
    ... Class A defines method foo() which is final. ... Compile both classes into files A.class and B.class. ... public void write ... explicitly tagged with the 'virtual' keyword, and the override uses the ...
    (comp.lang.java.programmer)
Loading