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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-23 06:21:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: Tue, 23 Sep 2003 15:29:47 +0200 Message-ID: <7og0nv098ssujg0dt64fa3vuvqpsamkdse@4ax.com> References: <568ede3c.0309160929.1d0d3d95@posting.google.com> <3F67AFB9.7040001@attbi.com> <3F6F0841.60607@attbi.com> <1064244399.683441@master.nyc.kbcfp.com> <1064319869.884066@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1064323283 4549618 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:42800 Date: 2003-09-23T15:29:47+02:00 List-Id: On Tue, 23 Sep 2003 08:24:28 -0400, Hyman Rosen wrote: >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. This is again a bad example. A persistent Window will probably have other implementation. Because, usually it is required to have an ability to work with persistent objects directly in the data base. Compare it with hardware and memory-mapped device contexts. Neither can inherit much from another. This would be interface MI, which is already accepted (to my utmost amazement (:-)). >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. I do not propose that. There are many ways to decouple things. A need to cast usually indicates a design problem, as a matter of fact. The source of the problem (either a language deficiency or a programmer's fault) is another story. Should I come to the situation you describe, I'd probably redesign the container to make it more specialized. Doing so I will have a variety of possibilities not to use MI. Again your example neither in favour of nor against MI. Better is to make streams controlled. Me and other have several times mentioned it, but nobody from the opposite side responded. This is an indication that the example is good. (:-)) --- Regards, Dmitry Kazakov www.dmitry-kazakov.de