jguy@lilith.EBay.Sun.COM (Jeff Bone) (11/30/90)
Please --- cut me a bit of slack here. I'm not very used to working with
lisp in general and xlisp in particular.
(Maybe if I hadn't slept through those classes --- pun intended ;)
This seems like it should be really trivial to do but I just can't seem
to "get it". I'd like to define a class of "transparent" objects which
behave as follows:
(send anObject :getval 'symbol)
(send anObject :setval 'symbol 'values)
-- where --
:getval returns value of variable called "symbol" on object
or some error if "symbol" isn't an [ic]var on object
:setval sets the value of variable called "symbol" on object
or some error if "symbol" isn't an [ic]var on object
I can define a method :getX on an object which spits back the value
of some variable X I name in the method body, but I'd like to have
a more general mechanism. Just can't get it. (I know, I know ---
scheme makes more sense.)
The application of this is to use xlisp's object facilities as a sort
of OODBMS where you can store values on predefined object templates
and then query them.
Since objects can contain other objects as instance variables, the
following becomes possible:
;; where anObject's "contents" ivar is another object
(send (send anObject :getval 'contents) :getval 'foo)
ad infinitum. This cries out for a shorthand, perhaps something like
the following:
\symbol "dereferences" symbol
you can then do
symbol\symbol\symbol ... (etc)
to provide a "path" to the thing you want. Then you can do
(= anObject\anotherObject\someObject\someNumber 3) ...
and
(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?
(2) Does this *really* muddy up the semantics?
(3) Does the "object path" syntax make sense, and
what does it do to the semantics?
(4) How hard would this be to implement in some
fashion? Could you do it from within the
language somehow, or would it require internal
changes?
(5) Who else is barking up this tree? ie, who
out there is doing OODBMS-type stuff in xlisp?
Thanks in advance for any and all comments, suggestions, and other
murmurings.
--
---- jbone@Sun.COM --------------------------------------------------
------------------------------------------------------ Jeff Bone ----
--
PS --- there's about a zillion other things relating to xlisp-as-OODBMS
on my mind. Here're some teasers: transparent and opaque objects
handled by the messaging mechanism. xlisp as a server (like, telnet
to it as opposed to the winterp-style "send-a-sexp" interaction). The
above cries out for threads --- each person gets their own interpreter
thread, all sharing the same adress space but with their own lexical
environment. Polymorphic message selectors (this is *neat*, IMHO),
so potentially many objects can match a propagated message and extract
useful information from the selector itself. This really means strings
as selectors, i.e.
(send aMagicWand :answer "*wave*wand*at $ *" '() '(method body...)
* matches any but ignores, $ binds to a "word"
where some string such as "Bozo waves the wand at Doofus." sent as
a message to aMagicWand (via some event propagation managaer) fires
off the method body with (for instance) $1 bound to "Doofus" within
the method body.
More: strings as names for objects, i.e. a string associated with an
object which is its "name", which \ can operate on. It *looks* like
an instance variable, but in fact it goes into a table of names in the
interpreter. Then you can:
(>= \"a magic wand"\charges 0) ...
Even more: some concept of permissions on/in objects. Transparent
and opaque objects are a start (I think there ought to be internal
support for this), but the concept should be extendable to ivars
and cvars as well. Transparent would be anybody reads/writes via
:getval and :setval, translucent would be :getval only, opaque means
only the object sees/writes the variable.
Still more: a method requirements clause *outside* the method body.
This would be something that would be evaluated by an object after it
receives a message but before execution of the method. Exectuion of
the method would then be predicated on the return of a T by the
requires clause.
Thoughts about all this?
DISCLAIMER: This really doesn't have anything to do with my employer
at all.toma@tekgvs.LABS.TEK.COM (Tom Almy) (12/01/90)
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