Re: Auto selection

On Tue, 28 Nov 2006 16:37:42 GMT, H. S. Lahman wrote:

Responding to Kazakov...

Note that in event-based interfaces there is no need to send data by
reference. That's because there is no return when an event is generated
since there could be an arbitrary delay between when an event is
generated and when it is consumed by the receiver in asynchronous
communications (e.g., distributed). Thus any values returned by the
receiver are sent back in a separate event data packet where the
sender/receiver roles are reversed.

No. It is because both parties either exactly know or don't care about the
states of each other. This is the source of all problems events have.

Asynchronous nature of events is not an advantage. It is a premise. When
states become too complex to reconstruction on the peers, the architecture
collapses.

Asynchronous communication is the most general representation of
communication.

Umm, probably not. It depends on what you understand under communication
and "representation of."

Some understand communication as sharing information. The word "sharing"
obviously excludes asynchronity. More you share, less can stay out of sync,
and reverse. Usually an asynchronous system can be viewed as synchronous in
the synchronization points (intervals, actually). Outside these intervals
it is in a transient (non-sync, exceptional) state.

Synchronous communications are just a special case of an
asynchronous description where the message order is deterministic.

No. This is a deterministic system. There is no need to use the word
"synchronous" in place of "deterministic." Synchronous means that the
states of *two* systems are both known at some definite time interval.
Deterministic means that states of the *same* system are predictable.

That's why in OOA/D messages are separated from methods and all behavior
communications are assumed to be asynchronous.

[clash of civilizations (:-))]

One can always implement
an asynchronous model in an environment that is inherently synchronous
without change. But one cannot always implement a synchronous model in
an inherently asynchronous environment without modification.

Vague, yet untrue. I suppose that without time constraints or alternatively
randomness, what you call asynchronous, can always be converted to
synchronous and back. In a hyper-computation framework they might turn
equivalent even with randomness, but I digress.

At a more philosophical level, the separation of message and method
ensures decoupling because the message sender does not need to know
anything about who the receiver is and what the message receiver does in
response. So the message sender can't depend on what the message
receiver does. That elimination of hierarchical dependencies is the
main benefit of OO development.

A philosophical objection to this could be - if you don't care what others
do, why do you bother them with your messages? [*] The modern scientific
method is based on the fundamental principle that anything, we don't know
of, first is considered non-existing.

---------
* Honorable contributors to comp.object, nothing personal meant! (:-))

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

Relevant Pages

  • Re: Auto selection
    ... Asynchronous communication is the most general representation of ... obviously excludes asynchronity. ... the synchronization points. ... Suppose I provide an OOA/D model using interacting object state machines ...
    (comp.object)
  • Re: Auto selection
    ... That's because there is no return when an event is generated since there could be an arbitrary delay between when an event is generated and when it is consumed by the receiver in asynchronous communications ... obviously excludes asynchronity. ... the synchronization points. ... At that point the 3GL will be essentially indistinguishable from a synchronous OOA/D model but it will clearly work correctly. ...
    (comp.object)