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!feeder.news-service.com!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 13 Sep 2010 11:19:10 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Preventing 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>
In-Reply-To: <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 13 Sep 2010 11:19:10 CEST
NNTP-Posting-Host: 0e08a98b.newsspool4.arcor-online.net
X-Trace: 
 DXC=POE4f7CAc>UU6b:FjPaGjQ4IUK<Cl32<Q4Fo<]lROoRQ8kF<OcfhCO[P5G5:g6GcaTnc\616M64>ZLh>_cHTX3j]h?bhmWm?>d_
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:14035
Date: 2010-09-13T11:19:10+02:00
List-Id: <comp.lang.ada>

On 13.09.10 09:13, Dmitry A. Kazakov wrote:
> On Mon, 13 Sep 2010 07:32:02 +0200, Florian Weimer wrote:
> 
>> * Maciej Sobczak:
>>
>>> If it implements an abstract interface, then why extending it further
>>> is a problem? [...]
>> the
>> information which subprograms call each other under what circumstances
>> leaks to the outside of the package.
>> [...]
> No, the actual problem here is re-dispatch. Just do not do that, it is
> always bad.
> 
> Final classes make no sense. I am glad that at least this was not borrowed
> by Ada ... yet.

People may have reasons that render extensibility of types undesirable,
even when internally the software will profit from re-dispatch. "Internally"
can refer to both the software and to the organization: in a controlled
environment (of people), dispatching at run time adds flexibility.

Reasons against extensibility just point to a very real phenomenon,
that of (mis)trust among the members of a group relevant to the program/
library: these include programmers, managers, sales personnel, users...
Will they trust the currently known programmers, trust future colleagues,
to use the extensible O-O library only in ways, say, covered by the
legal contract from year X?  (Hint: viral callbacks.)

If a system must reflect trust and mistrust, shouldn't the
mechanics of a language support both?  And hence---given the split
between Ada's non-tagged and tagged types---shouldn't the langauge
support "final" types?
Otherwise, which language lawyer can say it should or shouldn't,
when the issues are not technical, but social?


Georg