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 10.107.30.16 with SMTP id e16mr7582461ioe.22.1521564119411; Tue, 20 Mar 2018 09:41:59 -0700 (PDT) X-Received: by 2002:a9d:3464:: with SMTP id v91-v6mr27538otb.4.1521564119302; Tue, 20 Mar 2018 09:41:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!199-v6no816213itl.0!news-out.google.com!j10-v6ni111ite.0!nntp.google.com!u184-v6no382546ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 20 Mar 2018 09:41:59 -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: Tue, 20 Mar 2018 16:41:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 693616596 X-Received-Bytes: 4369 Xref: reader02.eternal-september.org comp.lang.ada:51084 Date: 2018-03-20T09:41:59-07:00 List-Id: On Sunday, March 18, 2018 at 8:33:26 AM UTC-5, Jeffrey R. Carter wrote: > Those interested can find Ada_GUI at >=20 > https://github.com/jrcarter/Ada_GUI =E2=80=9C=E2=80=A6 a better design for a GUI is for the GUI to have its own= task, so it doesn't require that its client give up a thread of control. G= UI events are communicated to the client through a protected queue of event= s. The client software can be written in the clearest way possible, unconst= rained by the GUI.=E2=80=9D Although I am sympathetic to your goals* in general, please allow me to pla= y devil's advocate for the current status quo thread design in nearly all G= UI-equipped OSes. The GUI does in fact have its own thread: the main thre= ad of the process. The =E2=80=9Cclient software can be written in the clea= rest way possible, unconstrained by the GUI=E2=80=9D by executing on one or= more threads other than the main thread. These other threads may be of an= y design imaginable (other than being the main thread). * One laudable goal is your de-emphasizing/eliminating of subroutine invoca= tion on the main thread. In most modern app designs, nearly all processing= that is not highly-tied to the GUI is performed on additional threads othe= r than the main thread. But invariably the final stage of processing is to= do something that delivers the results to the GUI executing on the main th= read. Invariably, nearly all modern GUI-equipped OSes have a execute-this-= subroutine/lambda-on-the-main-thread call in the GUI framework. This is si= lly over-emphasis on subroutines, when an interthread message queue (from t= he backend-processing threads to the GUI thread) would be the superior desi= gn. Asynchronous subroutine invocations from the GUI on the main thread (w= ith this concomitant increase in callbacks contributing to Callback Hell) i= s yet another dubious =E2=80=98innovation=E2=80=99 needed to work around th= e lack of a message-queue-based GUI; one gets async for free implicitly wit= h message-queue-based designs. > Those who like programming by extension won't like it. No programming by extension? I'd say that you just haven't gone far enough= down that message-based design road yet: Note that tag-length-value (TLV)= has been successfully utilized for decades throughout many IETF message fo= rmats to provide programming-by-extension-esque capabilities to message-que= ue-/messaging-based systems, when operating under the proviso that any tag = that the recipient does not recognize is to be ignored due to being from a = subsequent/newer release of software. Hence, programming-by-extension(-via= -OO-methods-as-subroutine-invocations) as commonly conceived is not entirel= y incompatible with messages in a message-queue-based system. The focus ch= anges from subroutine invocation to ignoring TLVs in recipients equipped wi= th older/less-featured software and processing those feature-added TLVs in = recipients equipped with newer/more-full-featured software. The mechanism = of programming by extension merely changes; the concept itself does not.