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,5add429c86f59001 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!feeder.news-service.com!feed.xsnews.nl!border-2.ams.xsnews.nl!newsfeed.freenet.de!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada vs Eiffel - Ada programmer approach Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <405b5054-4c8f-4e16-9ea8-503a9b9f976e@t21g2000yqi.googlegroups.com> <4A19765C.608@obry.net> <8105b65f-4de9-4653-b43a-d55ee33f072d@k2g2000yql.googlegroups.com> Date: Tue, 26 May 2009 16:51:35 +0200 Message-ID: <130yh6dv3l1lf$.1729u4tpolgwi.dlg@40tude.net> NNTP-Posting-Date: 26 May 2009 16:51:35 CEST NNTP-Posting-Host: 3ffa3066.newsspool1.arcor-online.net X-Trace: DXC=k@cm7>ihJR;B_cic==]BZ:afn4Fo<]lROoRa^YC2XCjHcbi\b@h]d3K4HeDNcfSJ;bb[eFCTGGVUmh?dLK[5LiR>kgbF5`o<7Dn9fe X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:6019 Date: 2009-05-26T16:51:35+02:00 List-Id: On Tue, 26 May 2009 06:37:49 -0700 (PDT), Ludovic Brenta wrote: > Pascal Obry wrote on comp.lang.ada: >> Tomek Walkuski a �crit : >>> - what, in your opinion, is worse in Ada, in contrast to Eiffel? >> >> - memory management (not GC - I know that there is nothing in the >> standard that forbid it - and this would be certainly really handful for >> some domain) > > I agree that it would be nice if some Ada compilers would provide an > optional garbage collector. One exists as a third-party add-on to GNAT > but I've never used it and it's not part of AdaCore's or the FSF's > distributions. > > In fact, I would like it if the garbage collector could optionally log > all deallocations while the program runs, so I can find memory leaks, > correct them, and remove the garbage collector later :) I don't think GC is a good idea. The language should allow scopes of all objects to be static. In most cases GC is used order to overcome certain language limitations like that T'Class cannot be a component. >> - multiple inheritance > > I'm not sure this is a good thing. In fact, I'm not sure simple > inheritance is always a good thing, either. I tend to prefer > composition and generics. But generics is a case of inheritance. When a type is put in a generic package, then an instance of the package produces a type that inherits the operations defined in the package. This is inheritance. BTW generics provide multiple inheritance: generic type T is ...; package A is procedure Foo (X : in out T); end A; generic type T is ...; generic B is procedure Bar (X : in out T); end B; type Multiple is ...; package Inherit_From_A is new A (Multiple); package Inherit_From_B is new B (Multiple); now Foo is inherited from A and Bar is inherited from B. It is possible to construct an example with generics that would not only add operations but also components to a record type. Nobody claims this bad... >> - DbC with pre-condition/post-condition/invariant > > When I read Bertrand Meyer's "Object-Oriented Software Construction", > I too thought that DbC was a brilliant idea. Now I'm less convinced. I > see two major drawbacks to DbC: > > - pre/post conditions and invariants involve run-time checks most of > the time (if not all the time). They slow the program down if enabled, > or become useless when disabled for performance. There should be no run-time contract checks. That is inconsistent: function Return_False return Boolean is -- The contract of Return_False is to return False begin if Is_OK (Return_False) then -- Is_OK returns True if Return_False satisfies its contract return True; else return False; end if; end Return_False; Now, if Return_False is OK, then Is_OK returns True and then Return_False returns True and so it is not OK. So is it, or is it not? Likewise Constraint_Error propagation is not a contract violation it is a part of the contract mandated by the language. It *must* propagate in specified cases, otherwise the program is incorrect. > I like static > checking much better; Ada provides a lot of that out of the box (much > more than Eiffel) and Spark goes way beyond even that. Yes. > - in most of the examples I saw in the literature, only very simple > subprograms would have a contract and the contract would mostly repeat > the body of the subprogram. This redundancy is counter-productive. That is when the contract is thought to be an equivalent of correctness proof. But it is not. A contract is much weaker, so that a program which fulfills its contract is not necessarily a correct program. Weaker contracts have an advantage to remain statically checkable for complex programs, leaving proofs of correctness aside. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de