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,c08a7609345f4e5 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!postnews.google.com!m1g2000vbh.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Limited use for limited with? Date: Sun, 10 Oct 2010 07:13:35 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <853314bc-0f79-435f-86a5-d7bcdd610731@c10g2000yqh.googlegroups.com> <36e886fa-b272-461f-bf86-a6b18366b64f@i5g2000yqe.googlegroups.com> <1eug9v5h5mf8d$.ud00hrz48lyr.dlg@40tude.net> <67044906-dacc-4526-b3f6-27e5323ab8fc@n3g2000yqb.googlegroups.com> <12chb4kbqt9ln$.zumsv1z9hqvk$.dlg@40tude.net> <292dd0bd-1fc4-4715-bb70-7655d0dc04eb@j24g2000yqa.googlegroups.com> <09c36bd6-edfa-42bf-8f33-e91b0a9b0737@26g2000yqv.googlegroups.com> NNTP-Posting-Host: 87.205.248.249 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1286720016 8858 127.0.0.1 (10 Oct 2010 14:13:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 10 Oct 2010 14:13:36 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m1g2000vbh.googlegroups.com; posting-host=87.205.248.249; 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.8) Gecko/20100722 Firefox/3.6.8,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:14474 Date: 2010-10-10T07:13:35-07:00 List-Id: On 9 Pa=C5=BA, 08:13, "Randy Brukardt" wrote: > Eventually, I changed most > of "links" to use names, which are then looked up in an appropriate index= . And what's in the index? The index becomes a registry with the same problems, just moved elsewhere. There are three options: 1. index/registry contains the actual objects - this has a big impact on how the objects are created; this might impose limitations that users will not want to accept 2. index/registry contains deep copies of the actual objects - then, the updates will not be propagated 3. index/registry contains access values to actual objects - then, beware dangling pointers 3a. objects know how to remove themselves from the index/registry - this has a big impact on how the objects are destroyed and on how the type is defined (forget interfaces); this in turn might impose limitations that users will not want to accept, either ? > A design that can't be expressed well in Ada is a poor design So let's be constructive. The problem is the following: - there is some activity happening in the environment that generates stimulation that should be handled by the program - there is some common interface for the propagation of this stimulation - users want to implement their handling routines In short (hey, that's a candidate for a design pattern): Event Handler. Ada provides nice solution for interrupts, but not all such scenarios are related to interrupts. Think about HTTP requests (AWS), RPC invocations (PolyORB), alarm notifications, and so on - in many cases all such things are delivered over the network, but this is not necessary. How would you express such a pattern in Ada? I still don't see a plausible solution and declaring the one that is simplest, most readable, and most flexible for the final user to be not "the Ada way" is not constructive, either. > I personally think that callbacks are a poor fit for Ada So how to solve the above problem in Ada properly? Or should we say that Ada is a poor fit for this class of problems instead? > It's not always > possible to avoid them (i.e. GUI programming), but I don't think they sho= uld > ever be introduced when there is an alternative. So what is the alternative? Please do not repeat the ones that were already dismissed. -- Maciej Sobczak * http://www.inspirel.com