Re: Standalone applications

[bcsaic!huntsai!rodney@beaver.cs.washington.edu (Rodney Daughtrey)]

Sorry it's taken me so long to reply; we've had some mail problems.	

        To: info-macl@cambridge.apple.com
	Subject: Re: defun doesn't call eval 
	In-Reply-To: alms's mail dated Mon, 12 Mar 90 21:58:47 EST
	Date: Mon, 12 Mar 90 23:25:21 -0500
	Status: RO
	
	
	> 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.

Sorry if my message was unclear.  If, upon startup, my standalone
application loads a file which has the forms

     (setq *my-dialog* (oneof *dialog* ...))

and

     (defobfun (window-show *my-dialog*)
        ...)

then this will work.  My problem with this is that this requires
separate source code files to be included with the "standalone"
application, which I would like to avoid if I can.  Another way
might be to have the standalone application run a function like 

   (defun create-a-dialog-at-runtime ()
     (setq *my-dialog* (oneof *dialog* ...))
     (defobfun (window-show *my-dialog*) ...))

(although I think all DEF- forms must be at the top level), or possibly

   (defun create-a-dialog-at-runtime ()
     (setq *my-dialog* (oneof *dialog*...))
     (eval '(defobfun (window-show *my-dialog*) ...)))
  
(I couldn't get either to work in a weak five-minute attempt.)
 
Anyway, I think Wayne is right:
 
	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).         **

Setting up a proper class for each different dialog that requires a class
definition (i.e. a dialog that has shadowed functions like WINDOW-SHOW, 
etc) solves the problem.  I just didn't see the logic in creating a
class for a single instance.
 
	(Whither_CLOS *) Wayne();

Sorry for such verbosity.

-- Rodney

----------
Rodney Daughtrey            E-mail: rodney%huntsai@atc.boeing.com
Huntsville AI Center                ...!uw-beaver!bcsaic!huntsai!rodney
Boeing Computer Services    Voice:  (205)-461-2352  Fax: (205)-461-2933