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=ham 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-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Properties Date: Wed, 1 Dec 2010 13:48:21 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net> <1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1291232903 13510 69.95.181.76 (1 Dec 2010 19:48:23 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 1 Dec 2010 19:48:23 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news2.google.com comp.lang.ada:16700 Date: 2010-12-01T13:48:21-06:00 List-Id: "Warren" wrote in message news:Xns9E417369AD1F4WarrensBlatherings@81.169.183.62... > Dmitry A. Kazakov expounded in > news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: > >> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote: >>> A library designed in Ada from the ground up, would be >>> better. >> >> But we cannot, think about a type- and task-safe >> notification mechanism. I have no idea how to do it without >> tagged tasks and protected objects. > > Perhaps the scope you have in mind is too large. Is it really > necessary to have the GUI operate outside of one task? Leave > the task handling to the application designer. We did this with Claw (Dmitry's argument that it is impossible doesn't hold water, since we tried to do all of the things that he suggests with Claw. Perhaps not in the way that he would like...) There definitely are problems where supporting tasking in the GUI is a significant help. For instance, a background task can update part of a window (say for a speed gauge); the main interface does not need to concern itself with keeping "background" information current. OTOH, supporting tasking in the GUI constrains what can be done in an event handler (Claw calls them "When_" routines), as it is quite easy to deadlock the system by having a handler do something that requires a lock that some other task is holding. It's not hard to avoid such situations, but we couldn't find any way to statically or dynamically check that the "rules" aren't violated. >> And I don't want to >> instantiate a generic each time I need an event handler. > > Agreed, but I don't believe we're stuck with that solution. > All you need is procedure'Access for the callback. Claw solely uses OOP to support event handlers. There are no explicit callbacks, and there are no generics to instantiate. (But instantiating a generic probably involves less typing than deriving an OOP type). IMHO, events cannot and should not be separated from the associated objects. >> And I do want the compiler to check that all events are handled. > > Hmmm, more of a scope problem, I think. Your requirements may > be part of the problem. This is not a problem in Claw, as all relevant events are always handled by every object. It's only necessary to write new handlers if you need additional actions on an event, and that could never be checked statically (or even dynamically), as it is specific to the problem being solved. >>> Part of the difficulty is that something like a GUI takes >>> so much effort to develop. To get one developed to a >>> "standard level" would likely require some level of >>> sponsorship. Especially if you want to also attempt to >>> make it platform neutral. >> >> The main problem is the interface of such a library. There >> are multiple parallel hierarchies need to be handled: a >> hierarchy of widget types, a hierarchy of widget >> containers, > > There are some challenges there, but I don't believe the fact > that you need widget containers is a show stopper. I don't see it as a problem at all. The standard Ada containers will handle Claw objects just fine (that's one of the reasons that I was very interested in the indefinite containers). [Note: Almost all Claw objects -- including all types of windows -- are non-limited with cloning semantics.] >> a hierarchy of event handlers (events are >> filtered, propagated, swallowed, re-generated). > > Not a problem with the callback approach, AFAICS. Callbacks are unstructured and lead to unmanagable spaggeti code. The same is true in any case if events are separated from the associated objects; so none of the things Dmitry talks about make sense for sane event handling. It's the objects that cooperate, not the events. ... > It really comes down to what is "good enough" for a standard > GUI library. Your requirements are desirable, but with > existing software technologies, it doesn't appear practical > AFAICS. > > Are there any GUI systems implemented that are fully static > checked? I don't think that even makes sense. The overriding property of a GUI is that objects are being created and destroyed under control of the user of the application, *not* under the control of the application or its programmer. We treated the user of the application as a "virtual" task, with the application itself being a different task that cooperates with the first. There is little there that can be determined statically (even if we hadn't used dispatching to deliver events to objects). Randy.