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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Wed, 21 Mar 2018 17:27:53 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:51098 Date: 2018-03-21T17:27:53+01:00 List-Id: On 21/03/2018 15:30, Dan'l Miller wrote: > 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. Scheduling implies that order of events is not preserved, right? How consistency is achieved? >> 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. That looks like inversion, exactly, when a method is bound to the instance of a source GUI element and not the instance of the target. (e.g. to the button rather than the container box holding the button). > “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.” That sounds like an excellent source of deadlocks and live-locks. But the main question is lack of structure. The hierarchy of events is of interest, flows do not matter. Any GUI has 3 dimensions: 1. Events (click) 2. Containment (parent-child) 3. Functional hierarchy (button-toggle button) Only one of them can be mapped onto a hierarchy of types. Most GUI choose #3. Would it be #1 instead? > 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. How would this work in the case of for a tree view? > A background on callback-based VIPER & MVVM without Rx added: > https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52 OK. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de