Hi Keith,
(I finally had some time to digest your e-mail). Thanks for the fixes!
I think I found the right package:
Magma seaside-kph.66
and merged the basis of your fixes.
I was using read strategies and found a bug in the depths generation process, here is a test which shows the problem.
Problem A: Subclass defines depths on instVars, superclass defines a depth for all instVars - raises an error .. not indexable.
This test case demonstrates the problem:
(MagmaSession new) readStrategy: (MaReadStrategy new onAny: Collection readToDepth: 2; forVariableNamed: 'tally' onAny: Dictionary readToDepth: 3; yourself).
Just for everyone elses benefit: Sets and Dictionarys should NEVER have a variable-specific read-strategy specified because they are treated logically. Keith is just using them as an easy demonstration of the bug. Along with the fix, I have changed Magma to signal an error if you try to specify a variable-specific strategy on a Set or Dictionary.
Problem B: Looking at the code, if a class defines a depth for all instVars, no attempt is made to see if the superclasses have defined a greater depth. The code has an (a max: b) statement as if to intend this behaviour but in reality it looks to me like it is actually (a max: a).
(MagmaSession new) readStrategy: (MaReadStrategy new onAny: Collection readToDepth: 3; onAny: Dictionary readToDepth: 2; yourself).
After thinking about it for hours I'm not convinced this is a bug. #inheritDeeperDepths is really about making it convenient to specify depths in superclasses so that subclasses do not have to be specified. The intent is to "fill in the blanks" when subclasses are not specified, but not override anything. If the user takes the trouble to specify a subclass, the assumption is it was for a reason, and Magma should therefore not override the effort.
I agree the code looks like it tried to do that, I have removed that.
I have also added a couple of methods to MagmaMutatingProxy, and a MagmaProxyStandIn class to improve the way that ObjectExplorer behaves. Now you can really explore how magma thinks when it is using read strategies.
I played around with this but did not see any difference. It sounds really interesting though! Can you describe a scenario I can use to see where this code will make a difference?
Then again, I never did find MagmaProxyStandIn, perhaps I am truly missing something here.
My fixes for A and B, have a couple of enhancements to the basic scheme. Negative depths are valid and subtracted from the inherited value. This can be useful so as to specify pulling a whole datastructure except this instVar or class type.
Agreed, but negative depths were already supported. So I did not integrate the server changes.
Thank you! Now I'm moving on to try to digest your other notes. :)