[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: defun doesn't call eval
- To: info-macl@cambridge.apple.com
- Subject: Re: defun doesn't call eval
- From: mesard@BBN.COM
- Date: Mon, 12 Mar 90 23:25:21 -0500
- In-reply-to: alms's mail dated Mon, 12 Mar 90 21:58:47 EST
> I think there is a misunderstanding here. Why don't you just
> do the DEFOBFUN? Why is there any need to call EVAL? You have to
> -execute- the DEFOBFUN after the dialog is created, but that doesn't
> require the evaluator. The DEFOBFUN has already been compiled. You
> just need to run it.
Excuse for jumping in here when there's a non-zero probability that I
don't know what I'm talking about, but:
I think what Rodney's saying is that his *MY-DIALOG* is something that
gets created by ONEOF (as opposed to DEFOBJECT). This is a Bad
Thing(tm) because it leads to exactly the sort of problem he describes.
It may seem counter-intuitive to define a class for a dialog since you
know that there's only going to be one instance of it when your program
executes. But the confusion that results from attaching OBFUNs directly
to instances is even worse.
Object Lisp will let you do the following:
(defobject a)
(defobfun (foo a) ()
(print 'in-foo-a))
(setq b (oneof a))
(defobfun (foo b) ()
(usual-foo)
(print 'in-foo-b))
(ask b (foo)) => IN-FOO-A
IN-FOO-B
But that doesn't mean you should do it. In particular, Object Lisp does
not distinguish between Classes and Instances. In theory this is a neat
thing. But in practice it can be confusing.
** DON'T define methods on Instances (thing's that have been ONEOFed); **
** define them on Classes (things that have been DEFOBJECTed). **
(Whither_CLOS *) Wayne();