Adding "virtual" slots to a class? Via MOP?
Kaelin Colclasure
definition of a class -- but not actually have instances allocate any
storage for those slots. Instead, I would like to provide accessors
which compute the values for those slots from the state of the instance.
My primary motivation for wanting these listed as slots in the class
definition is so that they will show up in the inspector.
I've been trying to grok "The Art of the Metaobject Protocol." It seems
like overriding #'compute-slots in 'standard-class would be a reasonable
place to start -- but pp. 180 documents that #'compute-slots has an
around-method (that cannot be overridden) which is responsible for
computing and storing "slot locations." [I am guessing that this means
the physical memory layout of instances of the class?]
Is it possible to do what I'm trying here? In this case, it seems like
the around-method defeats the purpose of #'compute-slots being over-
ridable... :-/
I'm working with ACL5.0, BTW...
Robert Monfera
dependent on how you implement your class. For example, you may have two
setter functions for setting the width property of an object, one in
percentage, one in pixels, and maybe you just have one slot that stores
it in the way it's more convenient. On a next version, you are free to
change your implementation, because you have not published your slots,
and you only provide access through generic functions (as you surely
know, slot readers/writers themselves are generic functions).
Stylistically, you probably do not want to bind more things than
necessary to implementation details like slots - where the necessary
things often mean no more than the reader/writer methods.
Also, if you just need it for your convenience only, probably you can
make your methods show up in your inspector, but this is
implementation-dependent. Both ACL and LW allows you to browse direct or
all methods belonging to a class.
Maybe you can tell us why you want some functions to fake slots, and
what you think about multiple argument methods in this context.
Regards
Robert
Barry Margolin
Robert Monfera <mon...@fisec.com> wrote:
>Maybe you can tell us why you want some functions to fake slots, and
>what you think about multiple argument methods in this context.
He answered that in the original post:
>> My primary motivation for wanting these listed as slots in the class
>> definition is so that they will show up in the inspector.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum
| My primary motivation for wanting these listed as slots in the class
| definition is so that they will show up in the inspector.
seems like what you really need is an inspector that knows more about
what to show you than just values of the specific slots. this seems a
much more general approach, too, so if you are supported customer of
Franz Inc's, you will find the source in sys:code;inspect.cl. let me
know if you are supported and need assistance.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Craig Brozefsky
> I've run into a situation where I would like to add some slots to the
> definition of a class -- but not actually have instances allocate any
> storage for those slots. Instead, I would like to provide accessors
> which compute the values for those slots from the state of the instance.
You should check out:
Andreas Paepcke. User-Level Language Crafting - Introducing the CLOS
Metaobject Protocol. In Andreas Paepcke, editor, Object-Oriented
Programming: The CLOS Perspective. MIT Press, 1993.
http://www-diglib.stanford.edu/~paepcke/shared-documents/mopintro.ps
You could very much just follow his tutorial with some slight
modifications and have what you want. I think once you see his
examples it will become clear to you how you could implement it. Me
and a co-worker have implemented something like this which shadows
slots in another process.
> Is it possible to do what I'm trying here? In this case, it seems like
> the around-method defeats the purpose of #'compute-slots being over-
> ridable... :-/
It is definetly possible.
--
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
Robert Monfera
> ...
> >Maybe you can tell us why you want some functions to fake slots, and
> >what you think about multiple argument methods in this context.
>
> He answered that in the original post:
True. I was asking about more general requirements like wanting to see
results of functions that have mandatory arguments beyond the object
itself. In the past, I was either happy inspecting slots, or wanted to
see the results of functions, without the arbitrary limitation that the
function may only have one mandatory argument, the object itself.
BTW, the AMOP contains an example on slot allocation to allow 'sparse
slots', where slot allocation is modified so that only bound slots are
actually allocated, to facilitate compact storage in an AI setting with
hundreds of slots, from which usually a small portion is bound. Based on
that example, it is possible to do what Kaelin asked. It's also possible
to write or extend a listener that shows results of methods.
Regards,
Robert
Kaelin Colclasure
news:37CD7F7E...@fisec.com...
[...]
> True. I was asking about more general requirements like wanting to see
> results of functions that have mandatory arguments beyond the object
> itself. In the past, I was either happy inspecting slots, or wanted to
> see the results of functions, without the arbitrary limitation that the
> function may only have one mandatory argument, the object itself.
In this case, I have a number of foreign structures defined for use with
IBM's MQSeries API. A typical example looks like this:
(ff:def-foreign-type MQOD
(:struct
(strucid (:array :char 4))
(version :int)
(object-type :int)
(object-name (:array :char 48))
(object-qmgr-name (:array :char 48))
(dynamic-q-name (:array :char 48))
(alternate-user-id (:array :char 12))
(recs-present :int)
(known-dest-count :int)
(unknown-dest-count :int)
(invalid-dest-count :int)
(object-rec-offset :int)
(response-rec-offset :int)
(object-rec-ptr (* :char))
(response-rec-ptr (* :char))
(alternate-security-id (:array :unsigned-char 40))
(resolved-q-name (:array :char 48))
(resolved-qmgr-name (:array :char 48))))
Playing with one of these in a listener looks something like this:
USER(172): (mqi::make-mqod 1 "foo" "" "")
#<foreign object of class MQI::MQOD>
USER(173): (inspect *)
A simple FOREIGN vector (85) @ #x20530c72
0-> simple T vector (7) = #(9130719 T 901 ...)
1-> The field #x2020444f
2-> The field #x00000003
3-> The field #x00000001
...
84-> The field #x2d737365
As you see, the inspector doesn't know about the "slot names," types,
etc. associated with a foreign :struct type. So my initial thought was
to define a CLOS class corresponding to each foreign type of interest,
which would reference an instance of the foreign type whenever a slot
access was done. The primary benefit I expected to glean from this
was that the inspector gives a nice, verbose presentation of CLOS
instances. However, once the "wrapper classes" existed, I expected to
find other useful applications for them as well. (For instance,
replacing calls to #'ff:fslot-value with regular accessors.)
As Eric pointed out in an earlier post, however, this is the long way
'round to simply getting more legible inspector output. And there are
definately simpler ways to streamline access to the foreign slots.
> BTW, the AMOP contains an example on slot allocation to allow 'sparse
> slots', where slot allocation is modified so that only bound slots are
> actually allocated, to facilitate compact storage in an AI setting with
> hundreds of slots, from which usually a small portion is bound. Based on
> that example, it is possible to do what Kaelin asked. It's also possible
> to write or extend a listener that shows results of methods.
I did eventually stumble across this part of AMOP. But even better, I got
a copy of Andreas Paepcke's paper as suggested by Craig. So, even though
I'm now convinced I don't need to do any MOP hackery to accomplish my
goals, I got to learn a lot about the MOP in the process. :-)
In summary, I'll work on customizing my inspector once I have the
necessary sources. Thanks to everyone who responded for the assistance!
-- Kaelin
Fernando Mato Mira
> I've run into a situation where I would like to add some slots to the
> definition of a class -- but not actually have instances allocate any
> storage for those slots. Instead, I would like to provide accessors
> which compute the values for those slots from the state of the instance.
>
> My primary motivation for wanting these listed as slots in the class
> definition is so that they will show up in the inspector.
>
> I've been trying to grok "The Art of the Metaobject Protocol." It seems
> like overriding #'compute-slots in 'standard-class would be a reasonable
You need to use slot definitions with allocation different from than
:instance or :class (say, :virtual),
and override SLOT-VALUE-USING-CLASS et al.
Klaus Schilling
> I've run into a situation where I would like to add some slots to the
> definition of a class -- but not actually have instances allocate any
> storage for those slots. Instead, I would like to provide accessors
> which compute the values for those slots from the state of the instance.
>
> My primary motivation for wanting these listed as slots in the class
> definition is so that they will show up in the inspector.
Goops, an object system for the Scheme implementation 'guile',
knows virtual slot. maybe one may snarf it from there. It is
snarfed in turn from either tiny clos or stklos, other clos-
inspired scheme object systems with mops, so maybe the trick
can be ported.
Klaus chilling
Marco Antoniotti
Klaus Schilling <kl...@schilling.cys.de> writes:
Why wouldn't an :allocation :class work? (I know there are problems)
Then you could just provide a specialized set of accessor methods to
provide the value. Of course, the interaction with the inspector is
implementation dependnet, so you do not have any guarantee of
uniformity.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa