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!news4.google.com!feeder.news-service.com!weretis.net!feeder3.news.weretis.net!news.szaf.org!news.gnuher.de!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Preventing type extensions
Date: Wed, 22 Sep 2010 21:41:35 +0200
Message-ID: <87aan9d0r4.fsf@mid.deneb.enyo.de>
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>
	<1qinn2jjeco14.1tvq2qzalwqbt$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: idssi.enyo.de 1285184495 6023 172.17.135.6 (22 Sep 2010 19:41:35 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:sdV+oCBB/iPd2Ua9YyzpAUECgG0=
Xref: g2news1.google.com comp.lang.ada:14192
Date: 2010-09-22T21:41:35+02:00
List-Id: <comp.lang.ada>

* Dmitry A. Kazakov:

>>> 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.

Perhaps not directly, but you still have the problem that you make the
extension because you want a behavioral change, and that change may
break other things.  (And unlike Objective Caml, Ada has downcasts, so
the fact that there are unblessed extensions is very visible even
without resorting to non-portable bit fiddling.)

>> It makes it more likely that you cannot write a useful extension.
>
> Why? I can override anything I need.

Yes, but you may have to copy source code from the parent type's
implementation because it won't pick up your new code automatically.

Back in mid-90s, there was a thought that it should be possible to
subclass all (public) classes and override all (public) methods.  This
design is still followed by the JDK.  I think this is quite the wrong
way to do OO.

>> 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?)

I want to make an explicit statement, "I do not support extending this
type" because I do not want to have the additional maintenance burden
of this dependency (or the debugging necessary because other code
breaks because there is an unexpected extension).  I can write this in
a comment, but I think it's better to make such things explicit in the
interface.