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@seaswork.com.ar www.seaswork.com.ar
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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