SPrevayler

Adrian Lienhard adi at netstyle.ch
Sun Mar 2 11:42:00 UTC 2003


Hi Avi

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

Yes, but you may also have methods in your central System that don't have to
be logged. Let's take the bank account example. I would implement the "bank"
as the central class which handels all relevant methods to log. Bank holds
customers and accounts. But now, if you wrap the bank with the proxy, you
also log simple getter messages like #accounts...

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

Yes, this doesn't seem to be a simple thing. It was more like a wish, which
would make it an almost perfect transparent persistence framework. I can
live very well with what it can do know.

Cheers,
Adrian

> 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