Re: Newbie question: Implementing a callback mechanism with Ada 83

["Jeffrey R. Carter" <jrcarter@acm.org>]

benibilme@gmail.com wrote:
> 
> What I wanted to achieve is to decouple the packages which are
> responsible for the handling of specific events. The initialization of
> each specific package would register for the events that it cares
> about and only become dependent to the event manager package. Event
> manager package would provide the interface for registering callbacks
> and the static data for the events, firing an event and removing a
> registration etc. A package that monitors a state or an event fires a
> defined event in the event manager package with the dynamic data and
> event manager module would call successively the registered callbacks
> in the different packages which are interested in the event. That was
> my intention. As a matter of fact that is a classic solution for event
> driven programs that I often use when I code with C. It adds one level
> of indirection and breaks the explicit coupling between the event
> generators and handlers. It is just a simple publish and subscribe
> paradigm. I present a very quick implementation of this module in C
> below. I wanted to implement this module in Ada 83 which I am failed
> to do.

What you're describing here is more an implementation than a description 
of what you have to do. But to my mind, what you achieve through such an 
approach is not a reduction in coupling, but an increase. The events and 
their handling subprograms must be coupled in such situations. However, 
it is structural coupling to have package A call subprograms in package 
B; it is control coupling to have package B give package A data 
(subprogram access values) that determine what actions package B takes.

> Of course I can solve my problem without this kind of capability. It
> will be brute force solution and according to me  an ugly solution.
> For example when an event occurs, the module that detected the event
> has to call the subprograms in different packages that are interested
> in the event. The packages will be tightly coupled to each other.  The
> package that triggers the event has to know the packages and the
> subprograms that interested in the event. I can see the Ada 83
> reasoning. Yes, the code will be more readable maybe and statically
> provable but very very verbose and inflexible. At least with my little
> Ada knowledge, that is what I can foresee right now.

I'm not prepared right now to wade through a bunch of C code for c.l.a. 
Besides, I'm not interested in how you would do something in C, but more 
in what you're trying to accomplish, so I can comment on something I do 
know, which is a good way to implement that in Ada. My personal bias is 
to avoid the use of access types and values whenever possible, and to 
hide them when not.

What you describe here is a static relationship between events and their 
handling subprograms, and then you say that a static solution to this 
static problem is something you consider "ugly". To my mind, a dynamic 
solution to a static problem is unnecessary complexity; it violates the 
KISS principle and is ugly.

Further, you think the static solution will be easier to read and more 
likely to be correct, but would prefer a less readable solution that is 
more likely to be incorrect. I find that incomprehensible.

SW engineering emphasizes ease of reading over ease of writing, and Ada, 
a language for SW engineering, explicitly adopts this attitude. 
"Verbose" is not a bad word among the SW engineers here.

Changing the action in response to an event in the static version 
involves looking at the code for the event and changing the subprogram 
that is called. In the callback case, it involves finding code not 
obviously related to the code for the event and changing the subprogram 
that is registered. The flexibility seems similar; the ease of making 
the change seems greater in the static case.

It's possible I've missed something since I haven't studied your C code 
in any detail.

> 1. The solution to having no access-to-subprogram type in Ada83 is
> usually passing the address of the function around and then in Ada a
> function can be declared to 'use' that address as it's own like so:

This is not something I would recommend, especially if it adds 
complexity to an otherwise simple problem.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31