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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!i32g2000pri.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Properties Date: Thu, 2 Dec 2010 01:57:49 -0800 (PST) Organization: http://groups.google.com Message-ID: <18768dde-5817-40b9-aaa1-03c620ad7187@i32g2000pri.googlegroups.com> References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net> <1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net> <1u5dftkqqi68c.10079qnqyyfwb$.dlg@40tude.net> <15tv4yga36dpi$.1hc09dlbgcmqe.dlg@40tude.net> NNTP-Posting-Host: 137.138.182.236 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1291283899 4622 127.0.0.1 (2 Dec 2010 09:58:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 2 Dec 2010 09:58:19 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i32g2000pri.googlegroups.com; posting-host=137.138.182.236; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:16712 Date: 2010-12-02T01:57:49-08:00 List-Id: On Dec 1, 10:45=A0pm, "Dmitry A. Kazakov" wrote: > > And how is this any different from, say, printing exactly the same log > > messages on standard output? > > It is just same. You can safely call Put_Line from any task. Wrong (AARM Annex A, 3.a): "simultaneous calls to Text_IO.Put will work properly, so long as they are going to two different files. On the other hand, simultaneous output to the same file constitutes erroneous use of shared variables." You might argue that by analogy two tasks should be able to modify the content of two distinct widgets, but that would be stretching definitions, as the agreement of what is "distinct" in GUI is quite arbitrary (ultimately, everything is a "child" of some uber-container, like a display and shares, so nothing is really distinct). > But if you do > Set_Text in GTK, that will crash your program. You mean - that will lead to erroneous execution? So it is exactly the same as with printing on standard output. Why do you expect to get better guarantees from GUI than from stdout? > > How do you solve this problem with Ada.Text_IO? Why the same solution > > cannot apply to GUI? > > I would like to have a similar solution, i.e. GUI things working without > switching the contexts. "Switching the contexts" is a technical term that relates to some platform implementation details. I don't see why this is relevant to GUIs, certainly not for performance reasons. And again, this is the same as with standard output. > On the context of the main GTK task you just call Set_Text. From an alien > task you need to instantiate a generic, or pass a closure, or override a > primitive operation of a query object and from the callback call to > Set_Text. The router calls the callback on the context of the main task. > You would not do this for each graphic operations. Instead you have a sor= t > of transactions, sets of operations executed in a group. This makes the > code look very different. As I said it is obtrusive. Is this a GUI problem or a general language problem? And is this really a proper design? I have implemented a GUI application recently. Not in Ada, but the general concepts are transferrable, as the tasking constraints were the same. The design involved a separate encapsulating "gui" package that exposed subprograms for *logical* (ie. domain-level) manipulations of the displayed content. The actual domain-oriented tasks of the application were not concerned with "setting a new text value of some widget", but rather with updating the domain-level information, whatever it was. By doing this, I have achieved not only the physical encapsulation of the display part and loose coupling between functional modules (heck, I could change that to a web service without touching anything else), which solved the tasking constraints, but also raised the level of operation for the rest of the program. And I don't consider it to be "obtrusive". With this experience in mind, if you insist on GUI to be task-safe, I think it is because you want the GUI library to support poor design practices. Having arbitrary application tasks calling Set_Text directly on some widget sounds like spaghetti. And that's why I'm not convinced. -- Maciej Sobczak * http://www.inspirel.com