After a long delay, I’m now starting to work on the RubyGOODS library
again. This library is intended to provide an interface to the GOODS OO
database, as well as serve as a more generic object persistence library
(eventually including an object-relational mapping layer).
What I’m actually working on now is an API based on the ODMG’s Object
Data Standard 3.0. To support this API, I need to be able to track, in
a generic fashion, when objects are accessed and modified. This job
would be simpler if I could simply wait until the end of a transaction
and compare live objects to snapshots of those objects as they existed
at the beginning of the transaction. Unfortunately, I need to obtain a
lock on an object PRIOR TO the access or modification.
I’m using proxy objects and AspectR to handle some of this
functionality, so I am able to trap all accesses to any persistent
object. However, I haven’t been able to think of any way to determine
if the object is about to be modified. The closest I can come is to
rely on the conventions of modifier methods ending in ‘=’ or ‘!’. But
this is not 100% reliable, considering methods such as Array#delete.
The only other way I can think of is to have users of the library call
some method to explicitly indicate that an object is about to be
modified, but I’d prefer a more transparent solution.
Does anyone have any thoughts?
Thanks.
···
–
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life’s externals may be transformed
or recombined. But it’s smaller than we think."
– Gene Wolfe, The Book of the Long Sun
i have a little experience tracking object states: i wrote some code to do
this for GUtopIa. your difficulty is the BEFORE modification. what i did when
tracking object state was powerful but far from elegant: i simply ran through
every method of an object and aliased it such that a hook/trap method was
called along with the original method. in my case i beleive i inserted the
call after the fact to see if anything changed. in your case you will want to
do it before the fact to “lock” the object (btw, how do you do that?)
hope that helps. if you’d like a copy of the code, to see what i did, let me
know. (note, Rich Kilmer deserves much thanks in helping me figure out how to
do this.)
i have a little experience tracking object states: i wrote some code to do
this for GUtopIa. your difficulty is the BEFORE modification. what i did when
tracking object state was powerful but far from elegant: i simply ran through
every method of an object and aliased it such that a hook/trap method was
called along with the original method. in my case i beleive i inserted the
call after the fact to see if anything changed. in your case you will want to
do it before the fact to “lock” the object (btw, how do you do that?)
Hi Tom,
Thanks for the input. AspectR provides functionality for wrapping
methods as you’ve done, so I’m using AspectR to do the wrapping. As for
the locking, I’m basically just locking the local object with a mutex
and calling the GOODS “cmd_lock” command. This, of course, is
GOODS-specific. I don’t have a general solution at this point.
At this point, I’m starting to wonder whether it’s even possible to trap
modifications to an object. I know that I could patch the interpreter
and modify rb_ivar_set, but I don’t want users to have to rely on a
patched interpreter.
Is there another way to accomplish what I want, either through C or Ruby
proper?
matz: Is this kind of need common enough to warrant an RCR?
···
–
Jason Voegele
“There is an essential core at the center of each man and woman that
remains unaltered no matter how life’s externals may be transformed
or recombined. But it’s smaller than we think.”
– Gene Wolfe, The Book of the Long Sun
Is there another way to accomplish what I want, either through C or Ruby
proper?
matz: Is this kind of need common enough to warrant an RCR?
I guess so. I prefer general hooking framework.
By this do you mean that the RCR should
Fit in well with the existing hooking framework, or
Specify a new hooking framework to replace what exists, or
Specify additional hooks in addition to the hooks that already exist, or
Something else that perhaps I didn’t understand.
Thanks,
···
In message “Re: Trapping Access/Modification of Objects” > on 03/02/10, Jason Voegele jason@jvoegele.com writes:
–
Jason Voegele
“There is an essential core at the center of each man and woman that
remains unaltered no matter how life’s externals may be transformed
or recombined. But it’s smaller than we think.”
– Gene Wolfe, The Book of the Long Sun
In message “Re: Trapping Access/Modification of Objects” on 03/02/12, Chad Fowler chadfowler@chadfowler.com writes:
By this do you mean that the RCR should
Fit in well with the existing hooking framework, or
Specify a new hooking framework to replace what exists, or
Specify additional hooks in addition to the hooks that already exist, or
Something else that perhaps I didn’t understand.
Either 2 or 3; I prefer 2 if possible.
What about adding aspects, possibly evolving from AspectR, out-of-the-box?
I like aspects, but I prefer CLOS-like method combination. I wish I
could add some kind of method combination (before, after, around to
name some) to Ruby in the future.
By the way, bundling AspectR to the distribution sounds nice anyway.
I wonder how Robert Feldt (and Avi) feel.
No problem for me. I haven’t touched it for long though so not sure if any
updates are needed etc.
Regards,
Robert
···
On Wed, 12 Feb 2003, Yukihiro Matsumoto wrote:
By this do you mean that the RCR should
Fit in well with the existing hooking framework, or
Specify a new hooking framework to replace what exists, or
Specify additional hooks in addition to the hooks that already exist, or
Something else that perhaps I didn’t understand.
Either 2 or 3; I prefer 2 if possible.
What about adding aspects, possibly evolving from AspectR, out-of-the-box?
I like aspects, but I prefer CLOS-like method combination. I wish I
could add some kind of method combination (before, after, around to
name some) to Ruby in the future.
By the way, bundling AspectR to the distribution sounds nice anyway.
I wonder how Robert Feldt (and Avi) feel.
Unfortunately I will not be able to work on this the coming 5-6 weeks.
After that yes, but if you want faster progress it’s probably better to
find someone else. Shouldn’t be too hard though, the aspectr source is
only a couple of 100 lines of Ruby code.
Regards,
Robert Feldt
···
On Wed, 12 Feb 2003, Yukihiro Matsumoto wrote:
By the way, bundling AspectR to the distribution sounds nice anyway.
I wonder how Robert Feldt (and Avi) feel.
No problem for me. I haven’t touched it for long though so not sure if any
updates are needed etc.
How should it be done? Are you willing to work on it, or do you want
to ask somebody else to work?
In message “Re: Trapping Access/Modification of Objects” on 03/02/13, Robert Feldt feldt@ce.chalmers.se writes:
Unfortunately I will not be able to work on this the coming 5-6 weeks.
I think I can wait. By the way, is it OK for you to rename it?
Namely I’d like to remove R from AspectR, it’s redundant.
Or is it better to keep “R” to avoid name crash?
In message “Re: Trapping Access/Modification of Objects” > on 03/02/13, Robert Feldt feldt@ce.chalmers.se writes:
Unfortunately I will not be able to work on this the coming 5-6 weeks.
I think I can wait. By the way, is it OK for you to rename it?
Namely I’d like to remove R from AspectR, it’s redundant.
Or is it better to keep “R” to avoid name crash?
Aspect is kind of general but maybe its ok. I dunno, you can decide and
I’ll comply…
