Re: Preventing type extensions

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

On Mon, 13 Sep 2010 23:21:28 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 13 Sep 2010 13:23:10 +0300, Niklas Holsti wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>>
>>>> re-dispatch is the problem, not aggregation or delegation. Don't implement
>>>> anything by means of re-dispatch and you will have no "callbacks." A type
>>>> extension cannot break anything in the parent's implementation unless it
>>>> re-dispatches.
>>> Conversely, there are architectures (sensible ones, in my opinion) in 
>>> which the extension is broken, or is difficult or cumbersome to 
>>> implement, if the parent does *not* re-dispatch.
>> 
>> I am not sure if these case aren't kludges caused by other language
>> deficiencies (e.g. lack of MI, MD, constructors etc).
> 
> I agree that re-dispatching can be used to simulate multiple dispatching 
> (MD) in Ada. I have no experience of languages that allow multiple 
> inheritance or multiple dispatch, so they are not in my design tool-kit. 
> But in the designs where I have used Ada re-dispatching, I don't see how 
> MI/MD could have replaced re-dispatching; they seem unrelated.

The only case where I am really using re-dispatch (though almost always
through the Rosen's trick) is layered protocols, where upper levels are
defined in terms of lower levels and the latter are implemented very late
(e.g. raw I/O operations). I strongly feel that this could be done simpler
and safer using MI and possibly MD.

> That would not have replaced re-dispatching, as I have used it. My 
> re-dispatching calls are interleaved in a more complex way with the 
> logic of the calling operation.

This is exactly the reason why I am reluctant to use it. I don't want to
fight this complexity, things are already complex without that.

>> One could consider dispatch restricted to class-wide operations while
>> allowing T'Class'Class. Then operations class-wide for T would be primitive
>> for T'Class. I.e. one could override them within T'Class'Class.
> 
> I think an example is needed before I can understand that. Which objects 
> are in T'Class'Class, but not in T'Class?

T'Class'Class would be a type which values are of T'Class. Such types would
appear if we could derive from T'Class.

> Re-dispatching calls from a primitive (non-class-wide) operation can 
> sometimes be replaced by dispatching calls from a class-wide operation, 
> and that can clarify a design. Perhaps your suggestion is an extension 
> of this?

When re-dispatch is consistently removed, primitive operations are replaced
by class-wide ones. Sometimes you want to replace a class-wide operation
itself rather than augment it by some primitive operation hook called from
it. A consistent way to override a class-wide operation would the class of
class-wide types. (I did not much ponder over this model)

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