ReadStrategy details

[Chris Muller]

Hi Keith,

> If I understand correctly with the current scheme a negative value on a
> variable will not prevent that variable actually being read. It may
> lessen the propagation of the depth of that strategy down that branch.

I don't understand why everyone wants to use negatives; they're really
not necessary and staying positive is, to me, much clearer.  A
depth-specification is local to the class hierarchy you are specifying
for.  If you use a negative depth then it would seem to be making a
suggestion for the referencing classes; which, to me, is
counter-intuitive to encapsulated thinking, at best.

The first time this came up, I thought I tried a negative once in a
workspace and it worked.  I will investigate it even though I'm not
seeing a good reason for them.  Won't someone explain it to me?

> I finally gave up on the existing numeric/array type implementation of
> the read strategy scheme and reimplemented it with a proper object
> oriented model that I could fully understand and am able to dissect in
> order to test alternative approaches.

Yes, this is one area of Magma that was originally optimized to a
compactly-serialized model, because the ReadStrategy's used to be sent
on every read request.  Since then they were cached on the server and
therefore the compact benefit was reduced.  But it already worked and
still better when frequently changing ReadStrategy's, since each
change means it serializes a new one and ships it up to the server.

Still, I will be interested to look at your reification.  Is it on SqueakSource?

> If you do specify higher levels you run the risk of an infinite
> recursion if your model has circular references. I.e. get me an A which
> contains B which points to A which I haven't got yet so, get me A.

Absolutely not.  The main thrust of Magma is to permit a rich, deep,
unfettered domain model, complete with cycles.  Disallowing them would
not be transparent at all.

Magma keeps track of where its been in any read-operation.  A and B
will materialize in the image pointing to each other.

> I wanted to use read strategies which say, read lots, except this
> branch. Or if not reading lots, at least ensure you read frequently
> indexable attributes such as id, name, type.

Ok, I see the wanting-to-use-negatives mindset here.  I'm pretty sure
this can be achieved by just specifying deep at a fairly abstract
superclass and, additionally, a shallow depth for the particular
branch you want to except.  Isn't that simple?

Regards,
  Chris