Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.clos Subject: Re: method definition question Message-ID: <1991Jun17.210108.29347@Think.COM> Date: 17 Jun 91 21:01:08 GMT References: Sender: news@Think.COM Reply-To: barmar@think.com Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 41 In article alanr@chopin.media-lab.media.mit.edu (Alan Ruttenberg) writes: >(deftype C () '(or A B)) > >(defmethod common ((instance C)) > ...) > >This doesn't work. (can't find class C) > >My only two choices seem to be to either replicate the code, or to factor the >body of the definition of common into a defun which is called by both. If A and B have any ancestors in common you could define the method on a common ancestor, and then use (check-type instance 'C) to catch misuse. But that's also pretty inelegant. I don't think there's a really elegant way to do this. OO programming generally depends on OO design, and it can get clumsy when you don't have the luxury of redesigning pieces. There was another posting today about adding a mixin to an existing class for which the source isn't available; that's the same kind of problem. Compound type specifiers such as OR can't be used as method specializers because they can introduce ambiguities into the class hierarchy. For instance, if you had (deftype OR1 () '(or A B)) (defmethod common ((instance OR1)) ...) (deftype OR2 () '(or B C)) (defmethod common ((instance OR2)) ...) and then did (common (make-instance 'B)), which method should be chosen? Of your two choices, I'd say the second one (factoring the common code into an ordinary function) is better. This is the nice thing about the fact that CLOS doesn't restrict slot access only to methods. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar