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 X-Received: by 2002:a24:72c6:: with SMTP id x189-v6mr547049itc.30.1521642601397; Wed, 21 Mar 2018 07:30:01 -0700 (PDT) X-Received: by 2002:a9d:6005:: with SMTP id h5-v6mr1260164otj.14.1521642600985; Wed, 21 Mar 2018 07:30:00 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!u184-v6no1456074ita.0!news-out.google.com!d3-v6ni1115itf.0!nntp.google.com!199-v6no1897926itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 21 Mar 2018 07:30:00 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada-Oriented GUI From: "Dan'l Miller" Injection-Date: Wed, 21 Mar 2018 14:30:01 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4940 X-Received-Body-CRC: 2679471761 Xref: reader02.eternal-september.org comp.lang.ada:51095 Date: 2018-03-21T07:30:00-07:00 List-Id: On Wednesday, March 21, 2018 at 3:25:14 AM UTC-5, Dmitry A. Kazakov wrote: > Why do you believe that event-loop architecture is better than callback= =20 > one? In the latter there at least no need to have an explicit loop and=20 > more importantly it can be made type safe if callback are primitive=20 > operations of interfaces. The Rx family of libraries across all various languages clearly reveals tha= t there exists a 3rd way of what API/personality is to be presented to app-= domain source code, which is neither raw callbacks nor (even worse) raw eve= nt loops. > In any case I do not see how this responds to major challenges of GUI=20 > design, e.g. structured filtering of events (widgets swallow events and= =20 > re-emit higher-level ones) Rx is directly aiming at solving that entire problem space. Quite well, bt= w, especially regarding concurrent scheduler-based handling events arriving= haphazard from drastically-different concerns: human GUI events, applicat= ion lifetime events, network traffic arrival events, asynchronous OS events= (e.g., filesystem I/O), and so forth. > or inversion when a button emits events, but=20 > it is the handler that must process them, so the case-statement or=20 > dispatching choice constrained by button interface must be in the=20 > handler code, not in the button or its descendant. In Rx, a different locality-of-reference is the guiding software-architectu= ral principle: the app-domain source code that instantiated a collection o= f GUI element(s) (e.g., button and its containing window/view) then almost = immediately =E2=80=98declares=E2=80=99 (unfortunately via imperative functi= on invocations in today's era of languages) who is to handle those events &= on which threads those events are to be scheduled. (Observation and handl= ing those events can be declared on different threads, such as observation = on the window's contract UI thread (or =E2=80=A2the=E2=80=A2 UI thread, dep= ending on OS) and handling on backend-processing threads. So instead of Bu= tton or subclass thereof housing the locality-of-reference infrastructurall= y (as a purely library/framework matter, where the GUI infrastructure has n= o clue about the app-lifetime events or the network packet-arrival events o= r the async filesystem I/O events or so forth), it is the point of allocati= on/instantiation in the app-domain source code (as a balance-all-the-wildly= -competing-concerns matter for the app-domain, where the app-domain can her= d these disparate cats more effectively from the GUI events, lifetime event= s, network events, or async OS events). Rx comes much much closer to a =E2= =80=A2composable system=E2=80=A2, where the app-domain programmer can say e= ffectively, =E2=80=9CI want this river of events and that river of events a= nd yet another river of events and still another river of events handled sa= nely even if interleaved arbitrarily without any of the events interrupting= or conflicting with the processing of any of the other events.=E2=80=9D (= As one might expect from a constellation of innovative technologies all com= ing from Microsoft Research,) Rx transforms MVVM to be a pure upstream-to-d= ownsteam single river. I think that it accomplishes the same river simplif= ication to VIPER, but I am currently in the process of working all that out= . Clearly Rx's single-direction river of data(flow) in MVVM is an astronom= ical advance over, say, the oft-cited Callback Hell in MVC that basically b= ecome Big Ball of Mud software architecture in any significantly-complex ap= p. A background on callback-based VIPER & MVVM without Rx added: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38d= e52