From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,29d8139471e3f53e
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Preventing type extensions
Date: Mon, 13 Sep 2010 13:23:10 +0300
Organization: Tidorum Ltd
Message-ID: <8f6cceFrv2U1@mid.individual.net>
References: <87iq2bfenl.fsf@mid.deneb.enyo.de>
 <874odv9npv.fsf@ludovic-brenta.org> <87y6b7cedd.fsf@mid.deneb.enyo.de>
 <66a3704c-54f9-4f04-8860-aa12f516134b@t3g2000vbb.googlegroups.com>
 <87d3sib44t.fsf@mid.deneb.enyo.de>
 <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net>
 <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net>
 <epkb3s8dfxk0$.1qdvo5vg2fsgh.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net ARxXxHTfdgm9lvnM2YKadgXdLP1yvYx2PWGIjR9AnOJUBG6o7P
Cancel-Lock: sha1:wDAlOdP+FMcl5rRbINkE/L1wSN8=
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)
In-Reply-To: <epkb3s8dfxk0$.1qdvo5vg2fsgh.dlg@40tude.net>
Xref: g2news1.google.com comp.lang.ada:14037
Date: 2010-09-13T13:23:10+03:00
List-Id: <comp.lang.ada>

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