From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: 15 Sep 92 21:05:46 GMT
	<a8wnd++.objsys@netcom.com> <1992Sep15.100426.20793@jyu.fi>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

(Chris Dollin) writes: ...

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

Taken literally this makes confusion between whether typing is latent or
not, and whether overload resolution is dynamic or not. Usually things
are paired in the same way; for example C++ has got explicit typing and
(by default) static resolution, while Smalltalk has got latent typing
and dynamic resolution, but other combinations are conceivable.

So, while it is true that usually explicit typing makes static
resolution easier, and latent typing invites the use of dynamic
resolution, neither connection is not necessary.

On the other hand probably you meant over to write 'static resolution'
and 'dynamic resolution' of overloading, and it was just an unfortunate
slip. If so, then I agree with the substance, with some proviso:

It's true that in some languages static or dynamic resolution is the
default, but that's really an implementation detail, even if
syntax is needed to explictitly indicate what kind of overload
resolution is desired.

  E.g. in smalltalk overload resolution is driven only by the name of the
  method and the mode/class of the first argument, the improperly called
  'receiver'; but if both are known/delcared at compile time, then overload
  resolution can well be done statically, which can be a big win. If I
  remember well Ralph Johnson has done quite a bit of interesting work in
  this area wrt (Typed) Smalltalk.

So I don't think it is fundamental to remark that:

On 15 Sep 92 10:04:26 GMT, sakkinen@jyu.fi (Markku Sakkinen) said:

sakkinen> Method/function selection is certainly performed at run time
sakkinen> in both C++ (although only for virtual functions) and Eiffel.

as that really is a nit, at least for C++; and in Eiffel, where
'virtual' is the (unexpressed) default, the implementation ensures that
explicit type information is used to reolve overloading at compile time
as much as possible, without programmer intervention.

What I find more disagreeable is the continued adoption, and certainly
it is not Sakkinen's fault, of confusing terminology:

sakkinen> The difference is that Smalltalk and similar languages have
sakkinen> dynamic ad-hoc polymorphism:

If you substitute 'dynamic typing' above with 'dynamic dispatching' then
I think you are really saying the same thing as Dollin.

sakkinen> any method that just happens to have the same name will gladly
sakkinen> be invoked.

What you (sakkinen) probably are saying above is that since Smalltalk
has latent typing, *and* dynamic overload resolution, all its procedures
are potentially polymorphic wrt all the object classes that implement
the protocol given by the union of the interface names it uses. Phew.
:-).

But this is really a a property of latent typing, not of dynamic
overload resolution.

The regrettable terminology you have used, born almost thirty years ago,
and perpetuated by the likes of the Cardelli/Wegner papers, names two
completely different things in similar ways, "polymorphism" and "ad hoc
polymorphism", as if one were a subset of the other.

They are really completly different concepts (one is a property of
procedure implementations, the other of procedure interfaces); calling
them both "polymorphism" causes confusion, between overload resolution
and latent typing.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.object