Re: Limited use for limited with?

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

On 11 Paź, 08:23, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> > 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

> In our case, we did this, because we needed the capability to make the
> object database persistent.

This is not my goal and there is no such requirement in my system, so
I don't consider it a reason for not using access types.

> >3. index/registry contains access values to actual objects

> 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.

> The contortions
> that we've gone through trying to use them for the queue containers

There is no obligation to use them where they are not adequate.
However, this says absolutely nothing about their use in those places
where they *are* useful.

> >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
>
> I don't believe this is true often enough in practice to be a reasonable
> stipulation.

Let's leave this requirement out of the picture. In fact, this is not
a requirement at all, but since Ada is a strongly-typed language,
there *must* be some specification of the protocol to pass the event
between program modules.

> >- users want to implement their handling routines
> > In short (hey, that's a candidate for a design pattern): Event Handler.

> Generally, such notifications include data.

Typically, yes.

> So you have to deliver the data
> somehow.

Typically, the data will be passed as a parameter of the dispatching
operation that defines the protocol.

> If you use a single interface, you break type safety with accessing
> the data

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?

> In every instance where I've had to do some sort of event handling, I've
> written a separate specification for each handler.

That's OK. These are defined as interfaces in my system.

> You have already decided on a solution, and are trying to shoehorn that into
> Ada.

No. I have reviewed the available language features and I have chosen
the one that allows me to solve the problem in the best way.
You still have not proven it otherwise. :-)

> But you are losing safety: both type safety and program safety (because
> of the dangling pointer issues) by doing so.

Type safety is not compromised. All operations are strongly types.
Some of them might be lately bound (dispatching), but all are strongly
typed. If you think otherwise, please explain.
Program safety is not compromised due to the fact that all reasonable
use cases guarantee that handlers outlive the registries.

> Every solution has tradeoffs,
> and you are picking the one that has the worst attributes from an Ada
> perspective

I'm still waiting for you to show it. And I still don't see it.

> For instance, for Claw, we used OOP dispatching to deliver events. This
> didn't require any Ada registration because Windows (and all other GUIs I've
> looked at) include a window handle in the event message;

GUI has the property that data sources and receivers are (typically)
bound in the 1:1 way. This allowed you to cheat a bit by piggy-backing
the object reference in the window handle.
This is not applicable in general.

> In the Web Server and Spam Filter, the events come from TCP/IP. In this
> case, we don't want a callback per-se because we want to treat each event as
> a "job", and schedule each "job" to be run by one of a pool of tasks.

Yes, this is a possible approach, but tasks and jobs are bound in the
1:N way (that is, each job is delivered to exactly one task). Basic
multitasking patterns involving queues or other buffers are OK for
this.
But it is not applicable in general. Think about how messed up it
would become for N:M case (each job delivered to potentially many
tasks).

It is true that in my system it *would* be possible to do this, but I
have chosen not to do it in order to avoid forcing the user (client
for you) to create additional tasks on his side. It is perfectly
possible to run the whole system in a single-tasking environment -
that is, the one that does not even support multiple tasks. Since my
system is targeted at embedded installations (among others), I
consider this to be an important feature. The user/client can always
add tasking if needed.

> I don't think that there is a general pattern that is acceptable.

I agree. But we are now discussing something different: you seem to
state that *some* pattern is *universally UNacceptable*, no matter
what - and this is something I don't agree with.

--
Maciej Sobczak * http://www.inspirel.com