Avi,

	I don't mean to uninstall the package. If you see the
ObjectAsMethodWrapper class, it has two methods:  #install and
#uninstall. This methods actually make the replacement of the
CompiledMethod by the wrapper and viceversa. So, when you have the
indexed collection arround, the classes will have their methods wrapped,
but when the indexedCollection is gone, you want those classes to be
normal again (uninstalling the method(s) that wraps it's original
compiled method(s)).

	About you automatic subclass approach, sounds good. You will
make it dependent or independent from GOODS client?

	regards,

Sebastián Sastre
 
ssastre at seaswork.com.ar 
Seaswork 
Special Software Solutions
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: Miércoles, 06 de Octubre de 2004 20:48
Para: The general-purpose Squeak developers list
Asunto: Re: Relative independence of odbs: IndexedCollection,the update
problem



On Oct 6, 2004, at 10:21 PM, Sebastián Sastre wrote:

> 	I put the methodwrapper in the index, so the lifetime of the
wrapper 
> will be in sync with the lifetime of the index who want's to be arawe 
> of that method call. I made a Registry class var in the indexes so
> they can receive a #finalize call when garbage collected, so they can
> uninstall the wrapper before disapear. I'm not completely convinced of
> this approach. Why they are not GC at once, and the wrapper 
> uninstalled,
> when a workspace script variable that is the only who knows the
> collection is set to nil? (they actually do but I only see it after
> sending Smalltalk garbageCollect) What do you think? When do you think
> the uninstallation of the methodWrappers should be done?

I'm not sure I understand - do you expect there ever to be a time when 
you don't have at least one index in your image?  As long as there's at 
least one (for any given domain class), won't you have to still have 
the MethodWrappers enabled?  It seems unlikely to me that, either in 
development or in production, the uninstallation case would ever 
naturally occur...

>  There are
> others/best approach you can see?

Well, I've actually been working on a different approach today, that I 
expect I'll probably release in the next couple of days.  It's intended 
to be used as a write barrier for GOODS (or other OODB clients), so it 
has different constraints from your homogenous indices.  I need to be 
able to detect writes on pretty much any class of object, which means 
that I can't afford to use MethodWrappers, since they're image wide; 
trapping writes to every Array in the system, for example, would not be 
a terribly good idea....  Instead, I'm using programatically built 
subclasses that override any potentially mutating methods, and trigger 
a notification if a mutation actually occurs, and I selectively change 
the class of the instances I'm interested in (using 
#primitiveChangeClassTo:) to use these special subclasses.

Anyway, it might be interesting for you to compare this implementation 
with what you've done with MethodWrappers.  I'll give more details when 
I release the code.

Avi

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.772 / Virus Database: 519 - Release Date: 01/10/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.772 / Virus Database: 519 - Release Date: 01/10/2004