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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,1116ece181be1aea
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-09-23 05:24:44 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!petbe.visi.com!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Tue, 23 Sep 2003 08:24:28 -0400
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5b) Gecko/20030917 Thunderbird/0.3a
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Is the Writing on the Wall for Ada?
References: <mailman.20.1062997816.295.comp.lang.ada@ada.eu.org>
 <q697b.8261$w41.4773@nwrdny02.gnilink.net> <wvbrad9emn3u.fsf@sun.com>
 <u3cez82oh.fsf@earthlink.net> <wvbr65jul87d.fsf@sun.com>
 <uhe3d7hmj.fsf@earthlink.net> <xXt9b.4926$U41.4024@nwrdny01.gnilink.net>
 <ud6e178aw.fsf@earthlink.net>
 <568ede3c.0309160929.1d0d3d95@posting.google.com>
 <3F67AFB9.7040001@attbi.com> <OJO9b.1195$U6.228@nwrdny03.gnilink.net>
 <3F6F0841.60607@attbi.com> <1064244399.683441@master.nyc.kbcfp.com>
 <jjuvmvoo493di1rpgm82c31r2qk0a8psr6@4ax.com>
In-Reply-To: <jjuvmvoo493di1rpgm82c31r2qk0a8psr6@4ax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1064319869.884066@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@aphelion.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1064319870  26503 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:42797
Date: 2003-09-23T08:24:28-04:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:
> Returning to the topic, the container of access IFoo'Class (an
> equivalent to C++ &IFoo) has the contract to keep objects of IFoo. It
> is a bad design if casting to IBar is required. There should be either
> a specialized container (**).  Alternatively, the design of the
> container should provide some identification methods, i.e. the
> container should know something about IBar.
> 
> What I wished to say is that your example is bad, because MI is not
> supposed to remedy one's design faults.

If I use a GUI library, I should not be surprised to find that the
library speaks in terms of pointers to and containers of things like
windows, cursors, fonts, and so forth.

If I use a persistence package, say, I should not be surprised that
it speaks of things like Serializable.

I should be able to combine these things into a single object which
has the behavior of both without having to redesign (and reimplement!)
the libraries which I am trying to use. While having lots of type tests
in bad, occasionally you do have to pass your object into the maw of
a third party library and get it back as a base pointer which you have
to turn back into your object.

You are calling this bad design, and in turn you propose that every
library must know about every other one, including those that have not
yet been written.