SPrevayler

Avi Bryant avi at beta4.com
Sun Mar 2 01:10:14 UTC 2003


On Sun, 2 Mar 2003, Adrian Lienhard wrote:

> 1. Proxy-Solution
> > every message that goes to the proxy is handeld by the prevalence layer.
> I think this is problematic because you log each message that is sent to the
> domain object, if it is relevant or not, making the log file much bigger
> than necessary. (With the current implementation you have to insert some
> return statements to be able to use the proxy to return objects other than
> self).
> So there should possibly be some kind of distinction if a method is
> effecting the state of the object or not!?
>
> 2. As it is now, you have to implement all your relevant methods in one main
> domain object (a PrevalentSystem). I think this will lead to a bad design of
> the domain model. It would be nice if it was possible to record all relevant
> messages to all domain objects.

Adrian,

As I see it only one of your points can be relevant at a time.  If, as is
the general idea with Prevayler, all mutation has to go through a central
"PrevalentSystem" object, then your first point doesn't hold - simple
queries can be implemented directly on the domain objects, with only
state-affecting actions having to go through the PrevalentSystem and be
logged.

If, as you suggest in your second point, we log message sends to all
domain objects, then we do indeed need some way to tell which methods
affect state and which do not (we also definitely need to assign unique
ids to these objects, so that the logged messages have a meaningful
receiver).  This is a much more complicated solution, however.  At that
point I think I would rather log the mutations themselves (all inst var
writes), which would be possible with a modified VM like Stephen's
Chango.

Just a crazy thought off the top of my head - if you did want to widen the
bottleneck a little bit, and allow arbitrary methods on your domain
objects to be marked as mutators, you could introduce an
AboutToModifyStateNotification, then use a handler that would log the
receiver, message, and arguments of the method context from which it was
signaled.  Ideally perhaps the notification would take a block with the
state-affecting code, so that it could ignore recursive invocations.

Avi



More information about the Squeak-dev mailing list