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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3ef3e78eacf6f938 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 24 Jul 2009 10:50:42 +0200 From: Georg Bauhaus Reply-To: rm.tsoh-bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.lang.ada Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? References: <24b1e02c-ef00-4adf-be11-e65277fc095c@j32g2000yqh.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <4a6975e3$0$32679$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 24 Jul 2009 10:50:43 CEST NNTP-Posting-Host: 4a90d270.newsspool2.arcor-online.net X-Trace: DXC=Ref8RNmnnEkPKPPVf;4hUjA9EHlD;3Ycb4Fo<]lROoRa^YC2XCjHcbi_ecdohc6IkgKQDKiQ7hlU?lX6FgX\0i X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.eiffel:407 comp.lang.ada:7309 Date: 2009-07-24T10:50:43+02:00 List-Id: Cesar Rabak wrote: > Colin Paul Gloster escreveu: >> On Wed, 22 Jul 2009, Simon J. Wright wrote: >> >> |--------------------------------------------------------------------| >> |"[..] | >> | | >> |And what will happen to this distinction with Point (2.0, 2.0);? | >> | | >> |You could use named parameter association, but *much* better to use | >> |proper types -- | >> | | >> |type Cartesian_Coordinate is record | >> | X : Metres; | >> | Y : Metres; | >> |end record; | >> | | >> |which makes it easy to (for instance) create appropriate functions | >> |"+", "-", "*", "/"." | >> |--------------------------------------------------------------------| >> >> Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an >> example of overloading which Eiffel can perform > > Since you citing me (incorrectly) and write this: > >> which he claimed that >> Ada can not manage. > > Writing a wrong assertion about a book it seems you only read a summary > made before a term exam, I suggest you get the text you implied you were > mentioning, specially the four paragraph on page 94 (OOSC 2nd ed.) and > pay attention to was is *actually* written there. Not being a fan of identical names for things not overridden (SPARK avoids this for Ada), the crux is, I think, allowing REAL into the discussion: new_point (p, q: REAL): POINT First, this is likely a create routine of POINT, REAL does not affect dispatching, POINT does. But when a new routine should make a new point from parameters of some other type, not REAL, we can, per advice, use a name that differs from `new_point` . And then we may refer to the "principle of non-deception" which will excuse us for not having, neither in Ada nor in Eiffel, Multiple Dispatch or, more Ada-like, many controlling parameters (dispatch smells of run-time things). And there's the problem, really. (*) (Not so much in syntactic vs semantic overload, purported to require dynamic dispatch, which is not the case for Ada or whenever the compiler can infer the run-time type. I think that even some SomeDialectOfEiffel has made an attempt in this direction.) `new_point` is using an unspecific type REAL. Something that we should not do, using Ada. REAL says little, except perhaps that the programmers make certain assumptions. Hopefully, they have augmented their unspecific REAL with a "require" for `new_point' documenting at least the range of permissible values or some such. Now "require" is presented as the "answer", and means of "non-decpetion" when overriding does use the same name as the overridden routine. (p.95) You could call it a workaround, though, for there is a better solution for method selection than principles. Still nothing wrong with using numeric types that are not as vague as REAL. For example, function new_point (p, q: EUCLIDEAN_DISTANCE) return POINT; New and distinct parameter types (that in general have compile time and run-time effects, hence are more than nicknames) are not a perfect solution, because the distinction doesn't work in all contexts. But still, I don't understand why a language design that puts the spot on types (O-O, modules, contracts, ...) starts coming up with all kinds of selected "principles" and "answers" when it comes to the lack of O-O in its elementary types, like INTEGER. Or maybe it is no good advertising when one would have to say, too difficult at the time; of the O-O model as made does not work well with elementary objects; or some such? Another, minor, flaw in this discussion is that Meyer, perhaps for reasons more or less obvious, refers to Ada 83 when he writes Ada; an exception is �33.7. (Interesting � in itself IMO.) (*) package Points is type Euclidean_Distance is digits 5 range 0.0 .. 45_000_000.0; type Point is tagged private; function New_Point(P, Q: Euclidean_Distance) return Point; type Near_Point is new Point with private; type Neighbourhood_Distance is new Euclidean_Distance range 0.0 .. 450.0; not overriding function New_Point(P, Q: Neighbourhood_Distance) return Near_Point; private type Point is tagged record X, Y : Euclidean_Distance; end record; type Near_Point is new Point with record Blocks: Boolean; end record; end Points;