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,103b407e8b68350b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-31 00:31:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.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: Anybody in US using ADA ? One silly idea.. Date: Fri, 31 Jan 2003 09:31:57 +0100 Message-ID: References: <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> <1043949507.331484@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: fu-berlin.de 1044001917 35647584 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:33631 Date: 2003-01-31T09:31:57+01:00 List-Id: On Thu, 30 Jan 2003 12:58:27 -0500, Hyman Rosen wrote: >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. I never said that Ada can this. >If there are operations common to all types, you should >be able to capture that in generics. Of course no. Generics are unable to make String a subtype of Unbounded_String. >> 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, Any OO language does this. > than a function which >operates on one should automatically operate on the other Only if it is inherited. >using convert-in/convert-out. Ada does this. >I do not see at all what this >has to do with any of OO, ADT, or separation. The point was that subtyping relation and substitutablity have nothing to do with the representation of the objects. As expected, if you separate interface and implementation. >> 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. Where you see a new concept? Circle and Ellise are two different types. So if you want make an Ellipse out of a Circle you must convert it. In Ada such conversions are called view-conversions. >> 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. Now tell me why for SetAxis : Circle x R x R -> Circle it is not reasonable to throw an exception? Do not you see that NN vs. Float is same as Circle vs. Ellipse? In both cases you produce a new [sub]type by constraining the base type. This says nothing about the representation of both. >> 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. Sort of: template double sine () { return X; } // // Works pretty well, as long X is close to zero // --- Regards, Dmitry Kazakov www.dmitry-kazakov.de