Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!zephyr.ens.tek.com!tekchips!tekgvs!toma From: toma@tekgvs.LABS.TEK.COM (Tom Almy) Newsgroups: comp.lang.lisp.x Subject: Re: xlisp as OODBMS, xlisp ?'s (LONG) Keywords: xlisp, OODBMS, other buzzwords Message-ID: <8511@tekgvs.LABS.TEK.COM> Date: 30 Nov 90 16:29:35 GMT References: <623@grapevine.EBay.Sun.COM> Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy) Organization: Tektronix, Inc., Beaverton, OR. Lines: 54 In article <623@grapevine.EBay.Sun.COM> jguy@lilith.EBay.Sun.COM (Jeff Bone) writes: [Jeff eventually wants to execute something on the order of the following to reference throught a chain of objects] >(send anObject\anotherObject\someObject :setval 'someNumber 4) >So, with all this in mind, the following questions: > (1) How *do* you get an object to cough up the value > of an instance variable whose name you specify > in the message? More generally, how can you get > an object to refer to an [ic]var you name in the > message? Ironically, I posted the answer to this question yesterday in my posting about (possible) bugs in EVAL and EVALHOOK. To reference an ivar or cvar with symbol name the value of x, (eval x) to set the ivar or cvar, (eval (list 'setq x (list 'quote value))) > (3) Does the "object path" syntax make sense, and > what does it do to the semantics? It destroys it. Send evaluates its arguments first so (send a\b\c :foo) will send the message :foo to the object which is the value of symbol a\b\c. The object path is not available to send. The path needs to be sent as an argument to the first object, and the method needs to break it down. Thus: (send a :foo-with-path 'b\c) But why should one have to do the dificult parsing of the path at execution time? Why not specify the path as a list? (send a :foo-with-path '(b c)) where the method is defined: (send theclass :answer :foo-with-path '(path) '((if (null path) (send self :foo) (send (eval (first path)) :foo-with-path (rest path))))) >Thanks in advance for any and all comments, suggestions, and other >murmurings. Your welcome. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply