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!feeder.news-service.com!xlned.com!feeder7.xlned.com!news2.euro.net!newsfeed.freenet.ag!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 13 Sep 2010 22:22:30 +0200
From: Georg Bauhaus <see.reply.to@maps.futureapps.de>
Reply-To: rm.tsoh-bauhaus@maps.futureapps.de
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Securing type extensions
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>
	<4c8e3f44$0$6769$9b4e6d93@newsspool3.arcor-online.net>
 <m2wrqplfq9.fsf@pushface.org>
In-Reply-To: <m2wrqplfq9.fsf@pushface.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4c8e87f8$0$6877$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 13 Sep 2010 22:22:16 CEST
NNTP-Posting-Host: 86ac1841.newsspool2.arcor-online.net
X-Trace: 
 DXC=0Qb=De@0K0?U`5g[@c]@J1A9EHlD;3Yc24Fo<]lROoR18kF<OcfhCO;hj;hXDBVB9>PCY\c7>ejV8GTT_fi\RoI3;F@<U8K66L6
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:14054
Date: 2010-09-13T22:22:16+02:00
List-Id: <comp.lang.ada>

Simon Wright wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> On 13.09.10 11:42, Dmitry A. Kazakov wrote:
>>
>>>> If a system must reflect trust and mistrust, shouldn't the
>>>> mechanics of a language support both?
>>> In Ada it is called visibility.
>> An event driven parser (or GUI) as an example: the gears of
>> the parser (or event loop) interact with the prim ops of
>> a user defined type.  The type will have been derived from
>> some abstract type that I provided.
>>
>> How will Ada's visibility rules help me trust the ops?
> 
> I don't see why this would be a problem for _you_? (unless you're
> worried about the support calls you might get!)

Yes, exactly, the design decision to declare a publicly tagged
type (which of course will not be "final") entails mutual obligations:
my calls on overridden subprograms will rely on profiles and further 
assumptions about overridden ops
(such as the LSP that has been mentioned), as do the overriding
ops of the user defined type.  This kind of mutual
trust is unrelated to Ada's visibility rules. At least I don't
see how visibility rules can ensure the same "static trust" that,
I think, Dmitry wants absence of re-dispatching to achieve.
Hence my question.

Another reason, not stated, to ask about an event driven parser
with user supplied type extensions was to learn how this can
be done without dispatching calls on subprograms not known
by the author of the parser (and possibly back).

(Calling user supplied prim ops might become a problem if
some bug (even a misuse) will make parties blame each
other. One of them might be socio-economically stronger.)


Georg