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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! Date: Tue, 1 Jul 2014 14:41:07 +0200 Organization: cbb software GmbH Message-ID: <1acivloppjafs$.15an4mn2871n1$.dlg@40tude.net> References: <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com> <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com> <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org> <5156oy7vhg99.17wu6q2ef45ke.dlg@40tude.net> <1d3612ad-f85a-489c-b4bc-0c23d5d67de3@googlegroups.com> <9vn9udxucq3n.1ejno042sc30t.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: QTaafVZuunHujkJPndFR7g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:20664 Date: 2014-07-01T14:41:07+02:00 List-Id: On Tue, 01 Jul 2014 11:28:42 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> For complex logic it is becomes almost impossible to structure the >> design along callback decomposition. It is no matter if callbacks are >> subprograms or full objects (procedural vs. OO decomposition), because >> the lines are already drawn. You cannot change anything. It is >> knitting standing on your head. >> >> Instead of the mess you wanted to put weight rather on the logic of >> the actions, their ordering and effects, than on the callbacks (I/O >> events). For this the individual callbacks which are logically >> coupled and ordered need to be represented as such in the source code, >> visually close to each other, best of all, as a thread of control >> where events pushing the actions are actually irrelevant to the logic. > > I think we must be arguing from different premises. > > In the system I was involved with, which involved state machines, > callbacks, and events, we had very little control over the order in > which the callbacks occurred. That is why you don't want them. I described an example of a multiple connection server, but a target tracking system might be as good. Once you identified a target you might wish to arrange all code dealing with the target in a single module, a "task". It is no different to a "task" servicing a connection. In both cases the driving force of the "task" is the I/O events. As events happen (callback invoked) they should be identified (the client for a connection, the target for a tracking system) and then the "task" servicing the object released. The service code does not see any callbacks. If acts as if it performed a blocking I/O operation = waiting for the next expected thing to happen. E.g. loop select Get_Coordinates (X, Y, Z); or delay Tracking_Timeout; Display ("You lost me!"); exit; end select; ... end loop; > You can't tell when a radar searching for > a target will detect it. You can't tell the exact time at which a > missile will leave the launcher after you've given the launch > command. You can't tell when the human in the loop will decide it was a > mistake and abort. Yes > And all of these external inputs were managed via callbacks. No. That is exactly the point. A design around callbacks is necessarily too low-level and exposed to all sorts of issues difficult to resolve. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de