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

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

On 10 Jan 2005 08:24:31 -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".
> 
> Hehe, you never give up, do you? ;)

Almost (:-))

> OK, "any way" = any way the message can be modified in:
> 
> If M1.A is an Integer, then the user shall be able to put any Integer
> in M1.A (at a specified time in the message M1 that happen to exist at
> that time).

But "to put something into" cannot be considered as an operation of
something more complex than just an untyped container. This is a weakness
of your analysis. If message is more than a chunk of raw memory then "to
put" is an implementation of something more meaningful than just copy from
one memory location to another. Once you factor out that semantics you will
probably be able to get rid of public components A, B, C etc.

> A Message is a record and an Action is a way to manipulate the Message.
> Not very mysterious to me.

So replace it with:

Message is a type
Action is an operation on it.
Scheduled item is a task calling operations of a message.

>>> 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.
> 
> I disagree. All message *types* are known.

But scheduling items are instances not types. Instances are unknown.

> The message *instances*
> flows through the system (having the time of their life so to speak;).
> Some of them untouched, and some of them manipulated in a predefined
> way. An action is that predefined way. And a bunch of actions
> programmed to occur at certain times constitutes an action schedule.

OK, why that bunch of actions cannot be just a piece of code in a task? Are
you writing an interpreter?

>>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?
> 
> No, my messages and actions do not have that relationship. (I see no
> absolute semantic in the terms Action and Message, that's why I've
> tried to explain what they mean in this system.)
> 
> Actions are invoked from a scheduler. The actions are performed on the
> instances that happen to exist (at the time each action is activated
> and if there is an action for that message type).
> 
> Messages then go to different devices an mean whatever they are
> supposed to these devices. The actions just do stuff with the messages
> before they (the messages) are passed on.

Shouldn't messages be formed rather in terms of device semantics? And why
should they exist before being sent to the devices? Is it a kind of
premature memory optimization?

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