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!news4.google.com!feeder.news-service.com!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.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>
 <878w35fqaa.fsf@mid.deneb.enyo.de>
Date: Mon, 13 Sep 2010 22:30:51 +0200
Message-ID: <1qinn2jjeco14.1tvq2qzalwqbt$.dlg@40tude.net>
NNTP-Posting-Date: 13 Sep 2010 22:30:50 CEST
NNTP-Posting-Host: 3f80afec.newsspool4.arcor-online.net
X-Trace: 
 DXC=H`Uln@>o4B]U6b:FjPaGjQ4IUK<Cl32<Q4Fo<]lROoRQ8kF<OcfhCO[bh?i8n2:a6[[6LHn;2LCV^[<mhadbfdU[19^N2_@aQ9[]f\L[m@5NT_
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:14055
Date: 2010-09-13T22:30:50+02:00
List-Id: <comp.lang.ada>

On Mon, 13 Sep 2010 20:32:13 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>>> Type extensions break encapsulation (at least if there non-abstract
>>> dispatching subprograms which contain some non-trivial code): the
>>> information which subprograms call each other under what circumstances
>>> leaks to the outside of the package. One very drastic way to
>>> implement that is to disallow type extensions for most non-abstract
>>> types you write, and consider the exceptions carefully.
>>
>> No, the actual problem here is re-dispatch. Just do not do that, it is
>> always bad.
> 
> How do you suggest to avoid redispatch?  Make non-dispatching calls to
> dispatching subprograms?

Yes.

> And how does this address the issue?

Because nothing can get broken by overriding, all targets are resolved.

> It makes it more likely that you cannot write a useful extension.

Why? I can override anything I need.

> Wouldn't it be better not to hide this aspect in the implementation?

This does not compute to me. Are you saying that if an operation gets
broken upon extension you won't allow to override it? (And if it is not
broken, why do you care?)

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