From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: Sun, 13 Sep 92 00:56:38 GMT
Organization: Object Systems

In article <KERS.92Sep7094418@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
[On static typing and multi-methods]

I'm giving up if we don't see eye to eye on this after this posting!-)
Static typing means types are available at compile-time.  Saying a
language is "statically typed" infers it is not "dynamically typed" which
means types are available at run-time.  Dynamically typed languages dispatch
based on the dynamic types of arguments.  This is *not* possible with
(strictly) statically typed languages because dynamic types are *not*
available.  So some clever people come up with some tricks (such as virtual
functions) which are dynamically bound but are still resolved at compile/link
time.  And some maintain types in their programs (a la Coplien) and emulate
dynamic typing in an ad hoc way.  In other words (and for the last time), you
can't switch on dynamic types if (by definition) they aren't there!  And
multi-methods are dispatched at run-time (dynamically).  And your (elided)
example doesn't seem relevant.

>[I'm sure I've asked you this before, Bob, but what's the difference between a
>``dynamic'' function and a ``static'' one?]

Whether the method/function selection is performed at compile-time (static
typing, e.g. C++, Eiffle) or at run-time (dynamic typing, e.g. CLOS, Smalltalk).

>   [8th time]
>
>8 repetitions of the same presumed information does not teaching make.

Excuse me, but I think this makes 10.  And its not "presumed" information.

>   Chris and I first got into it when Chris claimed that hierarchical
>   restrictions on packages were a good idea!  [This hasn't been popular 
>   lately and nor was it with me back then]
>
>Perhaps you could also explain to me what you think I meant at the time, since
>your description of it does not accord with my thinking about packages *now*,
>and I don't think I've moved position much in the past couple of years.

I simply argued there should be no hierarchical restriction and you argued
there should be because generics could always be used to solve the problem.
I believe I was pointing out the extreme convolution and added complexity
required to do so as opposed to the "natural" graph solution.

>CLOS sees there being two activities, that of defining/declaring generic
>functions (which are about interfaces) and that of defining/declaring methods
>for implementing that functionality *for particular argument combinations*.
>
>Hence my remark that methods, on their own, were NOT enough; you need [*1] the
>generic functions to invoke them.

Thanks for the CLOS summary.  But I don't see why generic functions are
necessary.  Just leave them out, Chris and you'll see all is well.  Really,
try an example by declaring a generic function and methods and simply delete
the generic function (which I'm not sure is even required in CLOS).  I can
see how to implement the system and I don't see any loss - not with method
combination, individual methods, or anything else - all is still well.

bob
objsys@netcom.com

P.S.  The elided generic function is left as an exercise to the reader.  Any
  *conflicts* may be posted.

P.P.S.  I haven't had time to consider Barry Margolin's response about
  CLOS's ability to handle the separation between type and class, but
  I recall his suggestion was really a separation between class specification
  and body and not really a type/class separation (or multiple-(simultaneous)
  implementations per type).  He said to just use accessor functions instead
  of direct instance variable access.