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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Preventing type extensions
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
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>
 <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com>
Date: Mon, 13 Sep 2010 15:55:08 +0200
Message-ID: <1igpdmyv8syzf.18mfvbnxizf82.dlg@40tude.net>
NNTP-Posting-Date: 13 Sep 2010 15:55:08 CEST
NNTP-Posting-Host: 7caababd.newsspool1.arcor-online.net
X-Trace: 
 DXC=l9ej3o[:2e;NTD<CL>55K=ic==]BZ:af>4Fo<]lROoR1<`=YMgDjhg26E_NldJ1nG2[6LHn;2LCV>7enW;^6ZC`4\`mfM[68DC3AHRno@R<?b6
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:14041
Date: 2010-09-13T15:55:08+02:00
List-Id: <comp.lang.ada>

On Mon, 13 Sep 2010 05:55:39 -0700 (PDT), Cyrille wrote:

> Far from it indeed. In order to follow the "simple dispatch" rule as
> described in OOTiA, one need to (almost) systematically re-dispatch.

This rule mandates re-dispatch.

> I understand the arguments in the other direction (against redispatch)
> but they do not look so compelling to me, especially in a context
> where LSP is understood and verified.

There is no substitutability issue when manifested types of objects are
honored. Actually it is the "simple dispatch" rule which can potentially
violate substitutability by using the type T in place of the type S when
dispatching to the operation of S.

When the object is declared of the type T it is no matter whether it was S
in one of its earlier lives or not.

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