Relative independence of odbs: IndexedCollection, the update problem

Sebastian Sastre ssastre at seaswork.com.ar
Mon Sep 27 14:47:55 UTC 2004


> 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? 

	Yes I know, so I'm considering to solve those problems by a less
general approach: making a restriction. This restriction could be
expensive to keep the update cheap enoguh.

	The restriction should be for the proxys/wrapper: 

	"They should trigger a message, only when the element receives a
message with 1 argument or more." 

	In this way, when you make the IndexedCollection, you can
configure it to be aware of the *configured* messages to make the
update. I'm aware that is more *manual*, less *intelligent*, but usefull
and flexible enough.

	For example:

	idxCol addIndex:(
		Index new 
			attribute:#name;
			updateWhenElementReceives:#name: ;
			updateWhenElementReceives:#firstName: ).

	Additionally, in real use, you can use the indexedCollection in
a way it only has indexes where they keys are String or Integers. I
can't see what else could be interesting to be holded in the keys. This
numbers or text can be holded on an element's instVar or in a deeper
composition. In this last case you should put the accesors in the
element, configure the collection to #updateWhenElementReceives:#blah:
and you're done.

	What do you think?

	Anyway, with this approach, there still a problem in the domain
change that kills the hooked events (due to the identity lost) to catch
the triggers of the proxies. Any idea on how to solve this?

	Regards,

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


---
Outgoing 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
 




More information about the Squeak-dev mailing list