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-7-bit Path: g2news2.google.com!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!85.158.31.10.MISMATCH!newsfeed-0.progon.net!progon.net!news.qsc.de!newsfeed.kamp.net!newsfeed.kamp.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: Properties Date: Wed, 1 Dec 2010 16:20:44 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net> <1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net> Injection-Date: Wed, 1 Dec 2010 16:20:44 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="13419"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18w6wYDW/MG+0lqaTwnEIjVb9BxFSEiVMk=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:CujpGAz+R8VAjFMVRTuhud/INUc= Xref: g2news2.google.com comp.lang.ada:16694 Date: 2010-12-01T16:20:44+00:00 List-Id: 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. > 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. > 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. >> 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. > a hierarchy of event handlers (events are > filtered, propagated, swallowed, re-generated). Not a problem with the callback approach, AFAICS. > At least > the first and the third must be statically checked, if we > really want it be Ada. Callbacks (events) are dynamic by nature. I think the best you can hope for is that your event handler is the correct kind (of callback) and that any parameters match are of the correct type. Both areas that Ada excells at. Asking for more than that, is perhaps a requirements problem. > Very likely that some composite > widgets (the second hierarchy) should also be static. I think tagged records are going to be the only real solution here, which is going to forgo static analysis. I think a tagged solution is at least as good as a C++ solution, but better due to Ada strengths. I think many folks could live with the dynamic nature of an Ada GUI library. > Then > there is a fourth hierarchy of widget properties. Some of > the properties are inherited from parent types, some are > from parent containers. > > All these hierarchies must play with each other. Ada's type > system is not mature for this. Perhaps not mature enough for your requirements. 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? Warren