Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Message-ID: <741@tetrauk.UUCP>
Date: 27 Sep 90 13:46:54 GMT
References: <15362@rouge.usl.edu>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 84

In article <15362@rouge.usl.edu> pcb@cacs.usl.edu (Peter C. Bahrs) writes:
>
>Without being for or against, how do you implement polymorphism without types?
>
>  For instance in OO|| syntax:
>
>   Class A;
>   A.(behavior x);
>   A.(behavior y);
>
>st. x and y are different objects.  How can you tell the difference?
>
>In C++ or OO|| you would define 
>    behavior (Classname id);
>    behavior (Classname2 id);
>and the compiler or interpreter will invoke the correct behavior/method based
>on the class of the incoming objects.  Otherwise each behavior
>must contain added code looking like a switch statement:
>	[code example]

What you are defining here is not polymorphism but function overloading, i.e.
multiple functions with the same name but different signatures in the same
class.  A language doesn't have to support overloading to allow polymorhism;
in fact Eiffel, the original subject of this thread, does not support
overloading of functions at all.

Polymorhism, using the same example style as above, would be:

	Class A;

	A = <instance of class B>;
	A.behaviour(x);

	A = <instance of class C>;
	A.behaviour(x);

or if you want it in Eiffel:

	a: A; b: B; c: C;

	b.Create; c.Create ;

	a := b; a.behaviour (x);
	a := c; a.behaviour (x);

The two calls to a.behaviour in fact refer to different objects, which belong
to different classes.  If the version of the "behaviour" routine invoked in
each case depends on the actual object type - i.e. (b) or (c), then the binding
is dynamic.  If the version of the routine is the one defined for (a)
regardless, the binding is static.

There is an implicit assumption here of reference semantics.  The objects (b)
and (c) are not copied into object (a) - (a) is merely a reference to the
actual objects.  If the assignments were copies, the (a) object would always be
an (a) object, and the copy operation between types would imply some form of
conversion.

The question of typing is how the rules for legality of assignment of either
(b) or (c) to (a) are defined in the language.  If the language is untyped
(Smalltalk, Objective-C), then there is no restriction whatever.  If object (c)
turns out not to have a "behaviour" routine, this is not detected until
run-time.  If the language is typed (Eiffel, C++), objects (b) and (c) must
conform to the type of (a), and are therefore guaranteed to have a "behaviour"
routine (or have object structures on which "behaviour" will work correctly if
the binding is static, as it may be in C++).  This usually means that they must
inherit from the class of (a), and so possess at least all the features of
class A.

The scope of the example only in fact requires that (b) and (c) possess a
"behaviour" routine, other routines possessed by (a) may not matter.  This
suggests that only partial conformance is actually required, but that's where
the design of the compiler starts to get fun ...

Sorry if this seems to be going back to basics, but the question did reveal
some fundamental misconceptions.

Anyone want to start a thread to discuss the benefits or otherwise of
overloading?

-- 
Rick Jones			The definition of atomic:
Tetra Ltd.				from the Greek meaning "indivisible"
Maidenhead, Berks, UK		So what is:
rick@tetrauk.uucp			an atomic explosion?