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-30 01:03:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.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: Thu, 30 Jan 2003 10:03:05 +0100 Message-ID: References: <1043339266.922562@master.nyc.kbcfp.com> <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> 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 1043917387 34548262 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:33596 Date: 2003-01-30T10:03:05+01:00 List-Id: On Wed, 29 Jan 2003 17:54:02 -0500, Hyman Rosen wrote: >Mark Biggar wrote: >> What is going on here is the fundamential paradox of OO systems. > >The OO lesson notwithstanding, I still don't see how >anyone thinks they can inherit method implementations >while not inheriting data representations. Aren't the >methods inextricably tied to the data they manipulate? Yes. But if you inherit a method it does not necessarily mean that this is the *same* method. Even in case of "class Circle : public Ellipse", when you call Ellipse::Foo on a Circle, the compiler will *add* some code to convert view. This means, that even if not overridden Circle::Foo is not Ellipse::Foo. Now, consider that this additional code not just shifts a reference, but creates a new object (Ellipse). In this case the representation of Circle can be any. >And this whole "isa" business is just a matter of what >methods the classes implement. A Circle "isa" Ellipse >as long as the interface doesn't include changing the >axes. Circle is substitutable in all in-methods of Ellipse. But does it mean that we should not use out-methods? Consider: subtype Non_Negative is Float range 0.0..Float'Last; Would you reimplement "-" for Non_Negative just because Non_Negative is not "isa" Float? [the result of "-" is an out-parameter] Surely not, you would just catch Constraint_Error as necessary. >I think the main problem is that people are >thinking instead of programming. (:-)) IMO the main problem that people are programming without thinking! >What is going on here >is the fundamental mistake of OO systems, which is >imagining that these things that you are writing in >order to get a computer program to produce a useful >result have all the properties of the things whose >names they bear, rather than the tiny subset which is >implemented. Absolutely. LSP cannot be enforced in all contexts. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de