From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Things that OO programming lacks
Date: Mon, 17 Nov 2014 14:29:29 +0000
Organization: A noiseless patient Spider
Message-ID: <ly7fytaoja.fsf@pushface.org>
References: <DA%7w.753721$Y4.288171@fx24.iad> <87389olqie.fsf@ixod.org>
	<zTF8w.509165$No4.167804@fx19.iad>
	<fca06fd0-6970-46a5-95b9-6b6317a37f7c@googlegroups.com>
	<aSG8w.567817$Q61.266688@fx13.iad> <m40odq$tdv$1@loke.gir.dk>
	<DbU8w.703256$Fo3.563225@fx09.iad> <m439g4$bq9$1@loke.gir.dk>
	<m43c6o$1v1$1@dont-email.me> <10d9w.55626$8w1.22302@fx12.iad>
	<150er0b62wsh3$.1xabmp81w5kdw.dlg@40tude.net>
	<m44gfo$1kb$1@speranza.aioe.org>
	<1azsoc77wjhmi$.1grmnnlq033tz.dlg@40tude.net>
	<m44m2p$f9k$1@speranza.aioe.org>
	<5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net>
	<m45757$huh$1@dont-email.me>
	<bezyvi09ddfl.1du5bw4wk652f$.dlg@40tude.net>
	<lysihj9gld.fsf@pushface.org>
	<1dwdgby88eh21$.k3nspjj0mme0.dlg@40tude.net>
	<lyfvdianse.fsf@pushface.org>
	<160lx4e9clifl.1kcusbxaei4r0$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="0ae4cc8b8d80483add419fa719d67148";
	logging-data="27561"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+gZzZoCknZdX0DblblVbVttjz4RqErVXM="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
Cancel-Lock: sha1:ULfaExIMC7bx+rGkWqCoopDSF+o=
	sha1:vKAz04uPAdbO/j3oWr9jgXSzQJw=
Xref: news.eternal-september.org comp.lang.ada:23465
Date: 2014-11-17T14:29:29+00:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Let you have two signals X, Y and want to produce Z=X+Y.  This is a
> trivial task in procedural, functional OO decomposition (not in
> relational one). With events, when X and Y are sampled
> (asynchronously), digitized (stochastically) and propagated through
> the system layers ([bounded] random delays), this does not work. You
> immediately run into a race condition.

I gree with you on this one. We never really ended up with a
satisfactory pattern. _Something_ has to remember the states so that
when one of them changes it can go and check the other one to decide
whether they're both set.

Very untidy-feeling to have two intermediate states, 'A set, waiting for
B' and 'B set, waiting for A', but possibly worth it to minimise the
amount of logic in code rather than having it visible in the state
machine.

> So even tasks considered trivial in other paradigms are hard problems
> in the event-driven one.

And the reverse? Nothing is the perfect approach for all problems.