Hi.

Adrian Lienhard wrote:

>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,
>>
The queries to the domain object (PrevalentSystem) go through the Prevayler.

>> 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. 
>
You can use PrevaleceProxy>>system method to query the state. But if you 
want to alter something you have to use the proxy.

>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
>>
I can follow you to the point until you go into the instVars and so on. 
It would be to detailed. I think that we have to see it a little bit 
more abstract.
I think we have to go away from details and think about how we could use 
the architecture of prevayler in another way to do what we want. At the 
moment I'm thinking about something that could give the trick. But it is 
to abstract to tell (Sorry - chaos in my brain ;-) )
At the moment I really don't know what the right way for SPrevayler is 
and it is a long way to go.

>>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
>>
In my mind that is something that is against the idea of prevalence. The 
programmer would have to think on more details. SPrevayler would become 
feature laden and that is something I don't want prevayler to be. In my 
mind it should be easy to use. You should not see a difference between 
code that uses prevayler and code that doesn't use prevayler.
I don't see a point for that at the moment. If there is a day when I 
think for this feature we need to code it that way ok but at the moment 
I'm not convinced. There is so much that can be handled with a clean 
design without manifesting the presistence layer in the code.

Regards

Marco