Re: Preventing type extensions

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

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.

Some time ago on c.l.a. we had a long discussion on the goodness or 
badness of re-dispatch, without coming to an agreement. I don't want to 
repeat that discussion, just to point out, again, that Dmitry's opinion 
is not universal.

Regarding Florian's view that re-dispatch "leaks" information about the 
internal implementation of the parent type, there was consensus in the 
earlier discussion that the occurrence of re-dispatch must be considered 
a public (interface) property of the module, and documented as such. I 
would not consider it a "leak", although I agree that it is an added 
"dependency".

Next question: Should the language provide means to express the uses of 
re-dispatch, in the declaration of a tagged type and its operations? For 
example, "primitive operation Foo calls primitive operation Bar with 
re-dispatch". An analog would be the exception contracts, as implemented 
in Java (where I believe they are not praised by all) and proposed for 
Ada. On my part I feel that a formal "re-dispatch contract" is not 
needed, partly because the presence of re-dispatch should be fairly 
simple for a static analyser to discover and report, but mainly because 
the important point is not that re-dispatch is used, but why and when it 
is used, and that would be hard to describe formally.

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