Relative independence of odbs: IndexedCollection, the update problem

Sebastian Sastre ssastre at seaswork.com.ar
Thu Sep 30 20:15:58 UTC 2004


Avi,

	after a detailed lecture of Stef's paper about controlling
method passing, I'd have to agree with you in the MethodWrappers
thecnique subject, as being the best approach for this case.

	By the way, Stef.. What a nice work you have done !

	So... I'm a little lost right now, but I'll study deeper this
MethodWrappers framework making experiments to see how much they already
are applicable.

	In your previous email you said that the system can know wich
methods modify a defined instVar by scanning the bytecode. As I never
make somethig like that I ask you to explain me a little more about
this.

	thank you,

	regards,

Sebastián Sastre
ssastre at seaswork.com.ar
www.seaswork.com.ar


> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Avi Bryant
> Enviado el: Sábado, 25 de Septiembre de 2004 14:30
> Para: The general-purpose Squeak developers list
> Asunto: Re: Relative independence of odbs: 
> IndexedCollection,the update problem
> 
> 
> 
> 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
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.767 / Virus Database: 514 - Release Date: 21/09/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
 




More information about the Squeak-dev mailing list