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
Path: 
 g2news1.google.com!news4.google.com!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: Tue, 14 Sep 2010 15:16:37 +0300
Organization: Tidorum Ltd
Message-ID: <8f97d6FobnU1@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>
 <8f6cceFrv2U1@mid.individual.net> <i6m402$gjp$1@news.eternal-september.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net szwf7/6gW5rPCIq4svSKiwJVxaukaFAzScZJzRDmnpuBiBzqGL
Cancel-Lock: sha1:f3/yCfQctXR8WQ1VCXo9qQdLa/U=
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)
In-Reply-To: <i6m402$gjp$1@news.eternal-september.org>
Xref: g2news1.google.com comp.lang.ada:14072
Date: 2010-09-14T15:16:37+03:00
List-Id: <comp.lang.ada>

J-P. Rosen wrote:
> Le 13/09/2010 12:23, Niklas Holsti a �crit :
>> 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.
>>
> <shameless_plug>
> I expect this to be a major topic of discussion at the OO for HR systems
> at SIGAda, since redispatch is what is causing the exponential explosion
> of tests.

Perhaps I am revealing my scanty knowledge of HR testing, but the 
"exponential explosion of tests" is news to me. Which phase of testing, 
and which coverage criterion, is affected so much by redispatching? 
Integration test? Some kind of path test?

For unit test I don't see why redispatch should increase the number of 
tests, since the called operation is typically stubbed.

If an operation of a parent type calls several other operations with 
redispatching, and several derived types override these called 
operations in diverse ways, perhaps you need to test the calling 
operation separately for each derived class. But if I understand 
Dmitry's standpoint correctly, he would avoid the redispatching by 
overriding the calling operation for each derived class, giving the same 
total number of operations to be tested, right?

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