MagmaReadStrategies

[Keith Hodges]

Dear Chris,

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

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

Also Problem C:
The ObjectExplorer behaviour is not completely in sync with Magma's 
behaviour. Ideally you want Magma to realize objects when you select 
them in explorer, not unexplicably due to explorers inner workings.

And finally very useful Logging "D"
------
Solutions:

In package 'magma seaside' I have included the fixes for A and B, in 
WAMagmaReadStrategyDefault.
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.

Logging: The class WAMagmaReadStrategyWithQ2Logging, logs realizations 
verbosely to the Q2Log, a logging facility available in Gjallar. This is 
very useful.

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.

----

cheers

Keith