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!.POSTED!not-for-mail From: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Wed, 28 Mar 2018 16:09:09 +0200 Organization: A noiseless patient Spider Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 28 Mar 2018 14:09:11 -0000 (UTC) Injection-Info: h2725194.stratoserver.net; posting-host="460fb46a4c0350d70ba2f75d850e57e2"; logging-data="12127"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18q7/JIDLjPS/BQAUSDyydj" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-Reply-To: Content-Language: en-US Cancel-Lock: sha1:e5gXz1YotSmLRMU8/moivoUukBc= Xref: reader02.eternal-september.org comp.lang.ada:51230 Date: 2018-03-28T16:09:09+02:00 List-Id: On 24/03/18 14:12, Dmitry A. Kazakov wrote: > On 2018-03-24 12:36, Alejandro R. Mosteo wrote: > >> Rx Observer contract: >> >> OnNext* (OnCompleted | OnError)? >> >> Events arrive once, thread-safely (OnNext call). End of sequences is >> notified once with success or failure, so cleanup is trivial. > > Well, how is that triviality any new or groundbreaking? The interfaces I > have in Simple Components for communication protocols are just like this. I'd say, more than groundbreaking, is a neat tool that fulfills a need and that has reached critical mass, so that you can find lots of resources and practitioners. >> The emitter of events is an Observable. The consumer is an Observer. >> Combinations of both are Operators. There are many predefined Operators >> to make life easy, addressing most needs that would be otherwise >> complex (e.g. tasking ones). > > Since I am using this model too, this is by no means any better than > other methods. In fact it is far worse! The reason why I am using it is > because there is no other way dealing with asynchronous I/O under the > constraint of limited number of tasks. The implementations of all > protocols in Simple Components are asynchronous. I'll take a look. > Now, programming this is like scratching your left ear with the right > hand. I keep on asking for co-routines in Ada to break out of this lousy > awful mess. To rein assorted mess of events/callbacks into a sequence > imperative calls to be a able to program it as if it were an > uninterrupted thread of control maintaining its state, just like if the > I/O were synchronous. I've never used coroutines. Since this kind of "imperative-like" sequences is what Rx provides, I understand that coroutines will allow the same without staying in the declarative realm? There are AIs for generators in Ada, maybe these will be among the chosen ones? >> For my own specification package: https://goo.gl/WQfpeV > > Good work, BTW. Thanks! Álex. > > [...] > >> Since you asked about TreeViews elsewhere, I see they somehow do it >> (but don't ask me how. It's probably ugly JS): >> https://react.rocks/tag/TreeView > > Too simple to judge. Usually problems start with columns, rendering nodes > differently depending on conditions, evaluation of the three dimensions etc. > >>> [There is nothing simple or elegant in event-controlled architectures. >>> Doing this for 20+ years (this is state of the art in automation >>> systems), I am pretty sure of.] >> >> The most elegant designs can turn ugly once things get real, that's for >> sure... > > No. This is another set properties: scalability, composability. >