Re: Limited use for limited with?

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

On 9 Paź, 08:13, "Randy Brukardt" <ra...@rrsoftware.com> 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 should
> 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