Re: OO problem: Performing actions on messages (very long, sorry)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 10 Jan 2005 00:42:44 -0800, per wrote:

>>How do you plan to maintain data consistency of a message if the user may
>>arbitrarily override its fields? I would try to do it more OO. To think
> 
> Well, that's the user's problem. Or rather, that's the point, sort of.
> See, this is a test equipment and shall enable modification of messages
> in "any" way in order to test how the test object (a computer) reacts.

The reaction could be "Access violation" (:-)) It is utterly untyped, or
non-OO, I should say. So it looks not very promising to to solve it using
OO. I still have an impression that you should return back to domain
analysis and find better objects than mysterious actions and messages. At
least there should be no place for the word "any".

>>about what can be done with a message. And consider action as an
>>implementation detail of a concrete type of messages. Then actions could
>>vanish. (Just a guess, I still can't tolerate both messages and actions in
>>one bottle. (:-))
>>
>>> Can an action, eg Override_A, exist without an M1 instance to "point"
>>> at?
>>
>>It cannot, this is the whole idea of access discriminants. They are never
>>null and cannot be changed. Otherwise one should use access types
>>(pointers).
>>
>>> Action has a different life-cycle than Message.
>>
>>That's no problem as long as its life in Message's one. For exampe:
>>
>>declare
>>  M : aliased M1;
>>begin
>>  ...
>>  declare
>>     A : Override_A (M'Access);
>>  begin
>>     ... -- The scope of the action A is nested
>>  end;
>>  ...
>>end;
> 
> How would you create a schedule of actions before any messages exist?
> (Schedule = Plan of what actions should be taken to what type of
> messages and when, created *before* any message instances exist)

So you schedule actions on something that even does not exist. It is a bit
strange. Normally scheduling depends on some state of *existing* scheduled
items. Probably this unconventional use of terms message and action is the
source of the misunderstanding. Aren't messages used to invoke actions?
Aren't scheduled actions invoked by messages from a scheduler?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de