Re: Preventing type extensions

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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