Re: Access types as parameters

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

Dmitry A. Kazakov wrote:
> On Thu, 13 Aug 2009 23:13:39 +0300, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Thu, 13 Aug 2009 11:34:20 +0300, Niklas Holsti wrote:
>>>
>>>> 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.
>>> Shudder...
>> Also an interesting reaction.
>>
>>> I consider re-dispatch is an indication of a language / design problem,
>>> because it is a hidden type error. An argument goes as follows. Once you
>>> have dispatched to some type T, the corresponding controlling parameter is
>>> of this type. Let we converted it to a class. If now it dispatches again to
>>> T, then that was just wasting time, if it dispatches to S /= T then it is a
>>> type error.
>> To me that is a very abstract and formalistic argument that is easily 
>> weaker than the practical benefits (providing sensible but overridable 
>> default behaviour while avoding code duplication) that make me use 
>> redispatching.
> 
> If some formal premises are not satisfied (a type consistency is one of
> them) then it is meaningless to talk about benefits. In an extreme case,
> you might have an erroneous program that occasionally yields a correct
> result. Would you see a practical benefit here?

As I said later in the message to which you are replying, I don't agree 
that redispatching implies a type inconsistency.

Do you use the word "erroneous" in the formal Ada sense, "erroneous 
execution"? Then could you please explain what kind of erroneous 
execution redispatching can cause, that cannot occur without using 
redispatching? As far as I understand, redispatching itself is safe; 
erroneous execution can only come from code in the operations that are 
invoked.

If your argument is just that a program with redispatching is more 
complex and thus more likely to contain programming errors, I partly 
agree; redispatching makes the sequence of invoked operations more 
dynamic and thus possibly harder to grasp and make correct. But this 
argument applies as well to any kind of run-time dispatching, not just 
to *re*-dispatching.

> Your initial example was about certain decomposition of operations into
> class-wide and primitive, so that a primitive operation would call to
> class-wide ones.

No, I think you mistunderstood my example, perhaps because I did not 
explain it clearly enough. The two operations in my example are both 
primitive, and can be independently overridden with behaviour suitable 
to derived types. The operations call each other with redispatching to 
activate the most suitable behaviour of each operation for the actual 
type of object.

> My point that such cases should be attributed to poor
> design

In the mind of the beholder, I think. You haven't shown *why* this 
design is "poor", except by your own design rules.

> There are also practical arguments that dispatching calls
> are slower,

I don't expect to get something for free. Dispatching calls are slower 
than statically bound calls, right? But you still use dispatching calls 
when needed, right?

> that re-dispatch requires referential semantics,

I don't see why, but I don't really care, as I have accepted (albeit 
reluctantly) that I need referential semantics anyway.

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