Re: Limited use for limited with?

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 13 Paź, 04:09, "Randy Brukardt" <ra...@rrsoftware.com> 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:
>
> >   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 you
> have done that, there no longer is a common mechanism for
> registering/triggering events -- you have to recode it separately for each
> 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 other
> 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 any
> 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