[Setools] Re: MagmaReadStrategies

[Chris Muller]

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.  :)