Re: Access types as parameters

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

On Sun, 16 Aug 2009 12:52:53 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 15 Aug 2009 22:19:41 +0300, Niklas Holsti wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>>> On Fri, 14 Aug 2009 19:03:52 +0300, Niklas Holsti wrote:
>>>>
>>>>> Of course not, only the point (within the class) of the implementation 
>>>>> of the currently executing, (possibly) inherited operation (the caller) 
>>>>> is determined. The actual type, as you well know, is any type in 
>>>>> T'Class, although it is written "T" in the operation profile.
>>>> No, the actual type is T, just because the operation declaration tells so.
>>> This seems to be the origin of our disagreement. You want to view the 
>>> object as of type T, although at run-time it may be a T-view of an 
>>> object of a derived type S. This means that you cannot redispatch. But 
>>> this does not entitle you to call redispatching "bad" in general.
>> 
>> Ada does not allow other cases, I mean dispatching while preserving a
>> class-wide view on the object. What comes in mind:
>> 
>> 1. procedure Foo (X : T'Class) is
>>    begin
>>        if X in S'Class then
>>          Bar (X); -- Now "dispatch" again
>>        elsif X in Q'Class then
>>          Baz (X); -- "dispatch" again
>> 
>> This is a form of re-dispatch since the tag of X is analyzed twice.
> 
> I don't see how this relates to our subject.

Just an example of how type tag is dealt with while keeping a class-wide
view of the object. Re-dispatching is no different. You publicly check the
tag, declare the result of T, but keep in the sleeve S. Let's play by
rules... (:-))

> Yes, that code looks at the 
> tag of X. Are you saying that any inspection of the tag of an object is 
> "bad design", except for the case of "basic" dispatching?

With a high degree of probability it is. In all cases I have to check tag I
feel myself guilty.

> Although I sometimes do it, I don't much like to inspect tags, as in Foo 
> above, because it couples the logic of a class-wide operation to the 
> existence and properties of certain explicitly named sub-classes, which 
> is fragile. But a redispatching call is not fragile in this way.

It is fragile because it has a behavior that is not determined by the
values attributed to the type T. Its behavior is determined by the values
of T'Class, which is an open-ended set.

>> Re-dispatch is a hack. What do you do is
>> semantically not inheritance but overriding with an instance of a generic
>> body, or some class-wide body. I think this is the key issue. 
> 
> I'm sorry, I don't understand why it is "semantically not inheritance". 

Type S inherits F from T by composition of T.F with a type conversion:

   S.F = T.F o S_from_T

That is the only way to define it in a typed language where S and T are
distinct types. This is also how Ada defines it. Any primitive operation
gets "re-declared" when you derive S from T.

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