Re: Real OO

[jsa@organon.com (Jon S Anthony)]

In article <Dqt13q.7AI@assip.csasyd.oz> donh@syd.csa.com.au (Don Harrison) writes:

> :> :  Even with some clairvoyance you'd have trouble as you
> :> :couldn't know about S when T and U were defined.  So, one possible
> :> :out would be to subclass them all and put the new frozen features
> :> :in these new "extraneous" classes and use them instead.
> :> 
> :> Hopefully, these comments are no longer relevant.
> :
> :No, these comments are still relevant.  First, clients can't define
> :them.  Second, you still need to be clairvoyant (define the operation
> :in one of the classes - even if it is application specific) or
> :introduce contrived/extraneous classes.  Another way to look at this
> :is that classwide operations allow you to take arbitrary universal
> :views of things - without having to go back and inappropriately fudge
> :the class definitions.
>
> Sorry, I don't see the problem. All you need to do is add the new
> operation to one of the classes. The supplier still declares it and
> you don't need to know ahead of time that it is required. It's
> semantically exactly the same as shoving it in a package
> somewhere. No extraneous classes are necessary.

The point is you either a) have to go back and hack the original class
(your current suggestion in this paragraph) or b) add some contrived
class.  The former a) case is clearly _much_ more egregious and
Joachim wisely goes for the latter b) case.  Now, the b) case can be
shrugged off as not being that big of a deal (as Joachim, again wisely
does...) but it is really pretty ugly to create conceptual entities
(as reflected by the contrived class...) just to pull this off.


> :> Is this what is meant by multiple dispatching?
> :
> :Yes.(tm/Kosh)
> 
> What's tm/Kosh?

Already covered by someone else :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com