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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Type naming conventions: Any_Foo Date: Mon, 9 Dec 2019 16:07:11 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 9 Dec 2019 22:07:12 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="32076"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:57699 Date: 2019-12-09T16:07:11-06:00 List-Id: "Jeffrey R. Carter" wrote in message news:qsipel$t3k$1@dont-email.me... > On 12/8/19 12:24 AM, Jere wrote: >> >> You are correct that you can write a high level abstraction wrapper >> around a GUI without exposing access types, but to Dmitry's point, the >> actual code that creates the GUI components has to use access types >> or some sort of referential data type. Your example GUI illustrates even >> this. When you look at ada_gui.adb, you will see multiple uses of >> access types: accesses to procedure callbacks, accesses to GUI >> components, >> uses of 'Access, etc. > > The implementation of Ada_GUI is a hack to let me test the feasibility of > the idea. I think a real implementation could be done without needing > access types, but have not looked into it in enough detail to be sure. > Even if it cannot be implemented without them, this discussion was about > what the pkg requires from its clients, so the implementation is > irrelevant. To me, this is the key point. Claw uses very few access types externally; the user view is generally one of objects, which can be aggregated in any way the user desires (records, arrays, containers, or allocation/access types). There were a few places where that model didn't work, although I think that was more because of the underlying system (Win32) and wanting to make all of the facilities available in some way, rather than because it was strictly necessary. Note that most Claw types are non-limited (thus allowing "cloning" - a copy being a "clone" of the original, and more importantly, return from functions) and task safe in the same way as Ada (so long as a single task only operates on a single object, everything will work -- tasks can work on different clones of the same underlying object). Randy.