home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!hal.com!decwrl!csus.edu!netcom.com!objsys
- From: objsys@netcom.com (Bob Hathaway)
- Newsgroups: comp.object
- Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
- Message-ID: <-6jnf=-.objsys@netcom.com>
- Date: 1 Sep 92 22:54:27 GMT
- References: <KERS.92Aug21150658@cdollin.hpl.hp.com> <t5anrkq.objsys@netcom.com> <BEVAN.92Aug28083247@tiger.cs.man.ac.uk>
- Organization: Object Systems
- Lines: 55
-
- >In article <31cnnr+.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
- > [ use CLOS terminology in preference to Bob + Coplien ]
- >
- > Then we'd be left with the more verbose but precise: "multiply-polymorphic
- > methods" terminology. People might still get confused over whether
- > "methods" referred to CLOS, classical OO or some other kind of method.
- >
- >So? Do you claim that if we all adopt your terminology there will be
- >no confusion?
-
- Ok. If there's confusion I won't add to it. I will use the unabbreviated
- terms multiple-argument dispatch or multiply-polymorphic methods when
- applicable. This makes clear the intended meaning without adding superfluous
- orthogonal detail.
-
- > CLOS stores methods specialized to a class with that class anyway.
- >
- >Shouldn't that be "CLOS stores methods specialized to _classes_ with
- >_those_ classes anyway" as the whole point is that it allows you to
- >specialise on more than one argument. Anyway, what does it matter how
- >it is _implemented_, it is the semantics that are important.
-
- Nope, storing it based on the first argument specializer is simple because
- of the left-to-right priority. The implementation I was referring to came
- from a subset implementation of CLOS and helps with reflection by allowing
- all methods specialized on a class to be accessed or listed together. This
- makes sense with a left-to-right argument specialization precedence which
- I believe emulates receiver priority. I mentioned it to show the close
- semantic similarity between the approaches.
-
- For example:
-
- 1) fn(A a, B b, C c, D d); // CLOS
- 2) class A{
- fn(B b, C c, D d);
- };
- 3) fn(A a, B b, C c, D d); // ordinary function
-
- 1) is not symmetrical, in fact it is almost the same as 2) but the CLOS style
- is still enforcing a left to right priority scheme for the rest of the
- parameters. In 2), The class member function does specialize on its receiver
- but is typically symmetrical for the rest of the arguments. 3) is truly
- symmetrical because it is a function and treats all arguments equally.
- Intercessory protocols can be used to provide arbitrary orthogonal argument
- matching but the defaults still define typical usage.
-
- So CLOS' approach to encapsulation - functions with complete access to all
- specialized (and perhaps non-specialized) arguments - is irrelevant from
- an argument matching perspective. And I still disagree with the dropping
- of protection on all but the first object since per-object protection is
- (reasonably) required for the separation of types and classes and IMHO without
- this separation a language is of little use for advanced applications.
-
- bob
- objsys@netcom.com
-