Re: Access types as parameters

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 14 Aug 2009 12:27:02 +0300, Niklas Holsti wrote:

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

It was merely a counterexample to "benefit" over "formalism". "Benefit" is
bounded by "formalism", not otherwise. If we consider re-dispatch doubtful
for formal reasons, that overrides any benefits (or we change the
formalism).

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

I disagree. Dispatching does not make it more complex assuming that all
implementations of the primitive operation are conform the interface. You
write the client program in terms of another type, of the type T'Class.
There is nothing automatically more complex in T'Class than in T. 

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

Yes, I understand this. The question is why it was decomposed in this way.
If one operation of the type T calls another operation of the same type.
Why should it dispatch. When you call an operation of the type S on T, that
is a type error to me. You have circumvented the type system, by an
explicit type conversion of T to T'Class. Do not we agree that type
conversions should be avoided?

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

I think I did. Why do you dispatch again, you already checked the tag. The
type is determined, the reader expects the code to correspond that type,
you break this convention. My concern is the semantics of the code.
Semantically a primitive operation has separate bodies for each type in the
class. This gets broken in your design. I.e. it is a third way of how
bodies are decomposed. I may agree that the language could offer more than
one body per class (class-wide) vs. one body per type (primitive). But so
far, a design should conform to the existing model.

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

Yes, but only if I cannot statically specify the type. Re-dispatch happens
at the places where I already determined the type, but for some reasons am
not satisfied with the outcome. Why? Strange...

>> that re-dispatch requires referential semantics,
> 
> I don't see why,

Because of the type tag. You need same representation for T and T'Class to
have T -> T'Class as a view conversion.

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

But it means that the design relies on referential semantics and cannot be
rewritten in terms of value semantics. Formally there should be something
fundamentally wrong with that, because there is no reason beyond 1.
optimization issues, 2. outer world communication, why referential
semantics is chosen. Yet we rely on it. Why?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de