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@seaswork.com.ar Seaswork Special Software Solutions 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: 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