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,103b407e8b68350b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-30 09:58:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool0902.news.uu.net!not-for-mail Date: Thu, 30 Jan 2003 12:58:27 -0500 From: Hyman Rosen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030116 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Anybody in US using ADA ? One silly idea.. References: <7iLY9.2401$qb1.464@nwrddc01.gnilink.net> <1043680098.61106@master.nyc.kbcfp.com> <3afc3v4uur2kvd53v4ul18b5npjfm188o3@4ax.com> <1043773909.385612@master.nyc.kbcfp.com> <1043855067.848326@master.nyc.kbcfp.com> <3OXZ9.85359$Ve4.6306@sccrnsc03> <1043880843.44251@master.nyc.kbcfp.com> <1043938782.244443@master.nyc.kbcfp.com> <25ji3v8n915cnnnaqpjvm4f7i01a66r9pf@4ax.com> In-Reply-To: <25ji3v8n915cnnnaqpjvm4f7i01a66r9pf@4ax.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1043949507.331484@master.nyc.kbcfp.com> Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) NNTP-Posting-Host: 204.253.250.10 X-Trace: 1043949508 4878 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:33606 Date: 2003-01-30T12:58:27-05:00 List-Id: Dmitry A. Kazakov wrote: > Consider Unbounded_String, Bounded_String, String. Why one cannot be a > subtype of another? In my view it is very reasonable, because all of > them are in fact just different representation of the same concept of > "array of characters". And a representation has to be no issue. You see, that's exactly what I'm talking about. You get lost because you're thinking about "concepts" instead of the nuts and bolts of the string types themselves. Ada is not an OO language in its entirety, and some of those strings are just arrays, so you're not going to get subtyping in the way you want. If there are operations common to all types, you should be able to capture that in generics. > No, it is an extension of OO and ADT. It is a simple consequence of > the principle that interface and implementation have to be separated. I don't see that at all. You want language support for the notion that if an object of type A can be converted to an object of type B, and vice versa, than a function which operates on one should automatically operate on the other using convert-in/convert-out. I do not see at all what this has to do with any of OO, ADT, or separation. > This what you require by saying: > class Circle : public Ellipse. > namely that Circle is convertible to Ellipse and back. No one else thinks that this is what A : B means, though. You would be better off if you stopped trying to overload everyone's understanding of inheritance with a new concept that no one associates with that. > C++ does not allow me to define my own type relations. Well, not for convert-in/convert-out, but plenty else. To do what you want, you can do struct A { struct BehaveLikeB : B { A &object; BehaveLikeB(A &o) : object(o) { } // Implement B methods, affecting A object }; BehaveLikeB likeB; A() : likeB(*this) { } B &asB() { return likeB; } }; void foo(B &); A anA; foo(anA.asB()); > define "-": NN x NN -> NN in a most reasonable way. Oh, sorry about that. For some reason my brain was saying unary minus, not subtraction. Yes, for subtraction throwing a constraint error is the way to go. > This could be an option if the software were never modified. In the > real world you would like to have as much compile-time checks as > possible, even for errors which will never occur in the given version > of the program. You never know in which direction the code will > evolve. And there is no better mechanism for compile-time checks than > the type system. But the template system gives you complete type safety, and compile-time checks! If you modify the code to use an unavailable operation, the compiler will tell you. All your method does is add an additional set of things that the types must be able to do even though the code doesn't need those operations. It is no more future- proof than the template version, because you do not know for sure that you will never need to add methods to the interface.