Re: Access types as parameters

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

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?

> What is more, a central benefit of inheritance is that an 
> object can be viewed as being of parent type T *and also* of derived 
> type S, depending on the context and your needs, so I don't accept that 
> redispatching "to a different type" implies a type error.

An object of the type S is already substitutable for T in the primitive
operations of T and the operations of T'Class. Why do you want to
re-dispatch? Re-dispatch means that an object pulls a trail of its history
of type conversions (view conversion is a case of) throughout all
substitutions of the object. This is a sufficiently more complex
programming model, which semantics is doubtful. Instead of plain type T you
have "S as T", or "S from R seen as T", and so on. That eliminates the
advantage of clean Ada model that distinguishes T and T'Class.

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. My point that such cases should be attributed to poor
design or maybe to a language problem. One argument I gave was type
inconsistency. There are also practical arguments that dispatching calls
are slower, that re-dispatch requires referential semantics, that there
would be no chance to have classes of by-value types like Integer etc.

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