Re: Access types as parameters

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:4a83d018$0$26303$4f793bc4@news.tdc.fi...
>> Randy Brukardt wrote:
>>
>>> You almost never want redispatching
>> That's interesting as my experience is the opposite: Most of the calls 
>> between primitive methods in my code use redispatching.
>>
>> My tagged types tend to have a hierarchy of primitive operations, for 
>> example an Overall_Method that implements some functionality by a sequence 
>> of calls to a Detail_Method. Some derived types override Detail_Method, so 
>> the call from Overall_Method to Detail_Method must redispatch. Some other 
>> (or the same) derived types override Overall_Method, so it cannot be 
>> class-wide.
> 
> It seems to me that one or the other of these routines ought to be 
> class-wide, the fact that neither can be is a design problem. But YMMV.

Thanks for understanding that YMMV.

Perhaps I can explain my context a bit more. Think of a class of 
problems that can be solved with a divide-and-conquer approach (this is 
not exactly my application, but it is similar). There are thus two 
operations: "Divide" a problem into cases, and "Conquer" a given case.

There is a general, but rather slow, way to Divide any problem in the 
class, so the root type implements a Divide operation that applies this 
general procedure and then calls Conquer for each case that it generates.

Some special kinds of problems (derived types and subclasses) have 
faster, specialized forms of Divide, so Divide is overridden for these 
types.

Each kind of problem (derived type) has a specific Conquer method, and 
so each derived type overrides the Conquer operation (which is usually 
abstract in the root type, in fact, but that is incidental).

> The primary reason that you don't (usually) want redispatch is that it is 
> hard to guarentee the semantics of a routine if it re-dispatches and thus 
> calls routines with unknown semantics.

Agreed, but that argument applies as well to any kind of run-time 
dispatching, not just *re*-dispatching, and thus for example to 
dispatching calls from class-wide operations.

If you have a class C with primitive operations Frobnicate and Dazzlify, 
which are expected to fulfil some application requirements, it is surely 
part of the programming task to ensure that each overriding Frobnicate 
or Dazzlify has the right semantics for its type, in whatever context it 
is called, whether using "basic" dispatching or redispatching. Assuming, 
of course, that the calls obey whatever preconditions are required for 
those operations.

> For Ada predefined libraries, we went 
> so far as to create a rule that calls do *not* redispatch - A(3.1/3)
> (You'll  have to look in the draft RM to see that one, since it was
> added in  response  to a question on Ada 2005:

That question came from me, I think (15 Feb 2007).

> see http://www.adaic.com/standards/1zrm/html/RM-A.html). To quote:
> 
> "For a descendant of a language-defined tagged type, the implementation 
> shall ensure that each inherited language-defined subprogram behaves as 
> described in this International Standard. In particular, overriding a 
> language-defined subprogram shall not alter the effect of any inherited 
> language-defined subprogram."

Nice to see that my question led to something, thanks.

> In short, don't redispatch in language-defined routines.

That was the solution I suggested in my question on Ada-Comment, as 
being the simplest solution. But it is not the only possible solution; 
another solution would have been to specify the redispatching that 
language-defined routines must or may do. As Tucker Taft commented, 
"redispatching must be seen as part of the *specification* of the 
primitive operation of a tagged type".

Of course, in my own code I carefully specify which operations use 
redispatching :-)

> Re-dispatching is really only safe semantically if you can guarentee that 
> the functionality of any overriding is a superset of that of the base 
> operation. But of course there is no way to guarentee that in Ada;

Unfortunately, Ada does not guarantee that you write a correct program, 
period. (But I do find that she helps.)

> Of course, sometimes the semantics aren't very firmly defined, and 
> redispatching works fine.

I would say, rather, that redispatching works fine *if* the semantics of 
the primitive operations *are* firmly defined, with redispatching in mind.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .