I see, this is not really useful if you use a persistency mechanism that dumps out the whole objects. The idea was that Pier knows using
Indeed.
the description what parts of the objects to serialize, something that is probably not easily controllable with a framework using the Smalltalk reach-ability to serialize objects.
So I would suggest that you remove this cache.
It seems that most of the properties in PRContext are not very useful when persisted.
My current approach explicitly copies the parts of the object that I wish to persist, and so now it is not absolutely necessary to remove this cache. I have removed Pier-Magma's use of this cache, and so it remains to see who else actually uses it.
What's the trouble with MAProxyObject instances?
I am not really sure of the ins and outs of this. I think that Magma was attempting to serialise part of the PRContext structure at the time. The proxy was to an Array of Commands, containing 8 items. Magma was looping through them to serialise them and asked for maInstSize which returned 9 rather than 8, owing to the fact that ProtoObject (i.e MAProxyObject) returns maInstSize as (^self class instSize + self basicSize ) differently to Object. I.e. the call to maInstSize is not being proxied. A fix would be to add an explicit maInstSize to MAProxyObject. I suspect that it would be worth setting up a test case for this one and to work out just what the desired behaviour actually is.
Keith
___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html