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 08:12:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!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 17:12:38 +0100 Message-ID: References: <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> <1044025336.3067@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 1044029559 35638092 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:33645 Date: 2003-01-31T17:12:38+01:00 List-Id: On Fri, 31 Jan 2003 10:02:15 -0500, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> Of course no. Generics are unable to make String a subtype of >> Unbounded_String. > >Ada generics, which labor under the restriction of needing to >specify things about the types on which they operate, not C++ >templates, which work as long as used operations are supported. I do not see how this would make one substitutable for another. >> Any OO language does this. > >Ada does not, C++ does not, I don't know for sure but I think >Eiffel does not. Smalltalk, maybe? Thunk code. >> Only if it is inherited. > >Why? Since you're converting, what possible relevance is there >to requiring that the operation be present in both types? I do not want flawed implicit type conversions. I want sub- and supertyping. If an implementation of sub-/supertyping is based on some conversions, I do not care. >> Ada does this. > >Really? It does convert-in/convert-out of different types? >I've never seen that before. Can you show me sample code? procedure Query (X : in out Float); -- The initial value is used as a default ... I : Integer := 10; begin Query (Float (I)); >> 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. > >As I said, no one else sees it this way. The normal OO view of >things is that if type B inherits from type A, then an object >of type B is also of type A. A given object may have only one type. >No conversion is required - the >object is already all of its base types. Sure? Try this: class A { public : int A_Field; }; class B { public : int B_Field; }; class C : public A, public B (}; A X; C Y; memcpy (&X, &Y, sizeof (Y)); If C is A why memcpy does not work? >> 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? > >It is reasonable to do so if you must have your Circle put into >places that expect modifiable Ellipses. But I believe the general >feeling is that having subtypes which restrict the legality of >parent operations in this way is not good design. I do not belive you, because the whole science is built using the principle of specialization by constraining. You could send a proposal to ARG to remove things like: subtype Positive is Integer range 0..Integer'Last; from Ada, but I do not think it will gain much support. (:-)) >I suppose >Eiffel fans will disagree with this, since they seem to love the >idiom of inheriting operations but only allowing the new subtype >as an argument. Shudder. Java uses this style as well, with all >sorts of operations in subtypes throwing not-implemeneted exceptions. Unfortunately there is no way out. An ability to constrain has its price. >> Sort of: >> template double sine () { return X; } >> // Works pretty well, as long X is close to zero > >Actually, C++ template parameters can't be doubles, but why is >this any worse, or different, than > >#include >#include > >struct SineInterface >{ virtual double operator()(double) const = 0; }; >struct SmallSine : SineInterface >{ double operator()(double x) const { return x; } }; >struct RealSine : SineInterface >{ double operator()(double x) const { return std::sin(x); } }; > >void UsesSine(const SineInterface &si1, const SineInterface &si2) >{ > for (double x = 0; x < 1e-5; x += 1e-7) > std::cout << x << ' ' << si1(x) << ' ' << si2(x) << '\n'; >} > >int main() >{ > UsesSine(SmallSine(), RealSine()); >} It is not better. My point was: we should check as much as possible at compile-time. Your point was: we should check only things actually used in the given program, as templates do. I gave you an example why it is a bad idea. You responded with another example. So the point stands. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de