Relative independence of odbs: IndexedCollection, the update problem

Avi Bryant avi at beta4.com
Sat Sep 25 17:29:35 UTC 2004


On Sep 25, 2004, at 3:45 PM, Sebastian Sastre wrote:

>     The main problem right now it's the update problem (point 6). When 
> anyone changes the value of an indexed attribute of a persistent 
> object, it should exist some kind of triggering mechanism, so the 
> IndexedCollection could tell to the corresponding index, to update 
> it's key and value corresponding to the mutating element.
>  
>     Hypothesis: what about making some kind of proxy or wrapper to 
> every element you add to this collection, to monitor (via DNU) every 
> message sent to the monitored element, and when appropiate, trigger 
> the change of the target attributes, so the collection could update 
> it's indexes?

There are a couple of problems with this - first, it's impossible to 
transparently ensure that a bare reference to the monitored object 
won't "escape", so that messages can be sent directly to it.  Second, 
how can you tell when a message mutates the object and when it doesn't? 
  You could keep a snapshot of the object and compare every time it got 
sent a message, but that's expensive.  If you're going to do that at 
all, you only want to do it for methods that might mutate the object.

Better, I think, would be to use a MethodWrappers (or ObjectsAsMethods, 
in Squeak) approach where you're passing around pointers to the actual 
object, but you modify its class (or a special subclass of its class) 
to have wrapped CompiledMethods in its methodDict.  You only need to 
wrap methods that set inst vars, which are easy to find by scanning the 
bytecode.  You only pay the cost on sends to those specific methods.  
The wrappers could do some kind of before/after comparison to see if 
the data actually changed, or you could just decide to always broadcast 
a change when a method is called that might have made one.

Don't we have a class-change prim now?  It used to require a #become:, 
which would be very expensive.  But if we can just swizzle the class 
pointer this could be a pretty decent approach.

I should also say that Stef has a good paper about this kind of stuff 
that I hope he'll post a link to.

Avi



More information about the Squeak-dev mailing list