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: a07f3367d7,c08a7609345f4e5 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!postnews.google.com!y31g2000vbt.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Limited use for limited with? Date: Wed, 13 Oct 2010 02:43:51 -0700 (PDT) Organization: http://groups.google.com Message-ID: <5b342ba5-5559-4f46-b48a-fc9436da1fd1@y31g2000vbt.googlegroups.com> 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> <1f38791b-a579-49ed-839c-e6ff3867de76@30g2000yqm.googlegroups.com> NNTP-Posting-Host: 77.65.97.192 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1286963031 7705 127.0.0.1 (13 Oct 2010 09:43:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 13 Oct 2010 09:43:51 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: y31g2000vbt.googlegroups.com; posting-host=77.65.97.192; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:15475 Date: 2010-10-13T02:43:51-07:00 List-Id: On 13 Pa=C5=BA, 04:09, "Randy Brukardt" wrote: > >> IMHO, Interfaces are worthless. > > >I hope you understand that this is a very strong statement. It > >basically stands in direct opposition to the work that has been done > >to introduce them into the language. > > I DID a lot of that work. [...] > we added it for them, not for me! This shows that there are very interesting forces in action in ARG. While we're at it, I believe that real multiple inheritance would be much better solution, but I accept interfaces as something that is still useful. Not having both of them would be very limiting. > >No, not at all. The type safety is not compromised in any way. > >Consider: > > > =C2=A0 procedure Handle_Event (H : Handler_Access; Data : in Integer); > > >(where type Handler_Access is access all Handler'Class) > > >In what way is the type safety of Data compromised here? > > It's not. But it is highly unlikely that different events need the same > data. So you have to have separate event handlers for each event. Once yo= u > have done that, there no longer is a common mechanism for > registering/triggering events -- you have to recode it separately for eac= h > event. Yes. > If that's the case, the concerns about coupling are pretty much > eliminated, as both the object and the event have to know about each othe= r > anyway. The decoupling allows to have N similar event sources and M similar event handlers. I find it frequently the case in control or monitoring systems, where many measurement systems produce data that can be processed or displayed by many clients. The decoupling is needed here so that data sources don't have to *statically* know their receivers. The "wiring" of the whole is driven by configuration, which is loaded at run-time. Georg already described the pattern in more detail, so I will not repeat it. > You and I must be thinking of different solutions, because I can't see an= y > way for that to work with a single handler registry type. And if you have > multiple such types, I don't see why you'd want to introduce the > complication: just deliver the events directly to the appropriate objects= . And here's the catch: event sources don't know their receivers until the program is run[*], so they cannot deliver the events *directly* to appropropriate objects. Some level of indirection is needed here and access values provide the required capability with very little (negligible) overhead. I think that this is the detail that we have missed in the discussion up to now. [*] Actually, the wiring of the components is not necessarily done at run-time, but certainly later than the event producer is compiled. In other words, the event producer is compiled as a module and delivered to the client that adds his handlers. There is no way for the producer to deliver events *directly* to handlers, as handlers are not known a priori. And generics are too complex to handle that cleanly. > >Program safety is not compromised due to the fact that all reasonable > >use cases guarantee that handlers outlive the registries. > > Again, you are saying that no one that will program your system will make= a > mistake. I'm saying that they will make a lot less mistakes when given a clear and readable API. The strategy seems to be working so far. > But I don't > think you are being realistic: for instance, I want to avoid allocating > objects when possible, because there are a lot less memory leaks Again: handlers are not allocated dynamically, they are typically static entities. Their associations with registries can be dynamic, though, but there is no danger in it. > Anyway, I think we have to agree to disagree on this one, because we don'= t > even have the same worldview. I think so. -- Maciej Sobczak * http://www.inspirel.com