Re: Ada-Oriented GUI

["Dan'l Miller" <optikos@verizon.net>]

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 
> one? In the latter there at least no need to have an explicit loop and 
> more importantly it can be made type safe if callback are primitive 
> operations of interfaces.

The Rx family of libraries across all various languages clearly reveals that 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 event loops.

> In any case I do not see how this responds to major challenges of GUI 
> design, e.g. structured filtering of events (widgets swallow events and 
> re-emit higher-level ones)

Rx is directly aiming at solving that entire problem space.  Quite well, btw, especially regarding concurrent scheduler-based handling events arriving haphazard from drastically-different concerns:  human GUI events, application 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 
> it is the handler that must process them, so the case-statement or 
> dispatching choice constrained by button interface must be in the 
> handler code, not in the button or its descendant.

In Rx, a different locality-of-reference is the guiding software-architectural principle:  the app-domain source code that instantiated a collection of GUI element(s) (e.g., button and its containing window/view) then almost immediately ‘declares’ (unfortunately via imperative function invocations in today's era of languages) who is to handle those events & on which threads those events are to be scheduled.  (Observation and handling those events can be declared on different threads, such as observation on the window's contract UI thread (or •the• UI thread, depending on OS) and handling on backend-processing threads.  So instead of Button or subclass thereof housing the locality-of-reference infrastructurally (as a purely library/framework matter, where the GUI infrastructure has no clue about the app-lifetime events or the network packet-arrival events or the async filesystem I/O events or so forth), it is the point of allocation/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 herd these disparate cats more effectively from the GUI events, lifetime events, network events, or async OS events).  Rx comes much much closer to a •composable system•, where the app-domain programmer can say effectively, “I want this river of events and that river of events and yet another river of events and still another river of events handled sanely even if interleaved arbitrarily without any of the events interrupting or conflicting with the processing of any of the other events.”  (As one might expect from a constellation of innovative technologies all coming from Microsoft Research,) Rx transforms MVVM to be a pure upstream-to-downsteam single river.  I think that it accomplishes the same river simplification 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 astronomical advance over, say, the oft-cited Callback Hell in MVC that basically become Big Ball of Mud software architecture in any significantly-complex app.

A background on callback-based VIPER & MVVM without Rx added:
https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52