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