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,56131a5c3acc678e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-10 09:11:11 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Question about OO programming in Ada Date: Wed, 10 Dec 2003 18:15:36 +0100 Message-ID: References: <1070889942.156714@master.nyc.kbcfp.com> <5lcBb.4138$UM4.2773@nwrdny01.gnilink.net> <1070976556.767919@master.nyc.kbcfp.com> <1070982307.973327@master.nyc.kbcfp.com> <7krbtv4bs50bm5gmdquteo3r0705ps58jt@4ax.com> <1070988116.464651@master.nyc.kbcfp.com> <7nudtvkbrm1i0a05d0n3v05j8q9nrbs7u8@4ax.com> <1071070064.52023@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1071076269 312947 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:3317 Date: 2003-12-10T18:15:36+01:00 List-Id: On Wed, 10 Dec 2003 10:27:43 -0500, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> No, the reason is that redispatch violates strong typing. If the >> contract of a subprogram is that some parameter has a specific type > >But it's only in your mind that such a contract exists. No contract no strong typing. >Certainly in C++, whenever you have a pointer or reference >to a class object, it is always the case that the pointed-to >object may in fact be of a more derived class. It is no problem if held in all contexts. This is the sense of having a contract. > Even in Ada, >don't derived classes inherit the subprograms of their base >class unless those are overridden? Or does Ada act as if the >subprograms had been rewritten line-for-line with the new >type in place of the old one? This is the whole idea of substitutability. >Not only that, but objects are often members of other objects. >Your "parameter of a specific type" may be a field of a record, >or a member of an array, or the base part of a derived object. >Redispatching is simply one way of going from the inner object >to the containing one, in much the way access discriminants are >touted here. You are confusing implementation inheritance [by extension] and aggregation. >> This is C++ design fault which uses same notation for >> both class-wide and specific types. > >The designers felt, and I think experience has borne out, that >redispatching behavior is what is wanted and expected. You can >always prevent redispatching, if that's what you want, by saying > p->SpecificClass::function(); Yep, and dispatch can be written using switch statement. It is Turing-complete anyway. >> Both faults stems from redispatch, which cannot be implemented in a >> type-safe and type-consistent way. > >Redispatch in C++ seems perfectly consistent and type-safe to me, >since I don't make false or wishful assumptions about what a >declaration means, but rather accept the language's specification >of that. I believe the same is true for Ada. > >> I don't argue against dispatch tables. My point that a dispatch table >> belongs to a subroutine, not to an object. Then OO, as an approach, >> has little to do with implementation issues. It only states that there >> are dispatching subroutines. Note, subroutines, not "dispatching >> objects". > >That may be your view, but it certainly isn't the ordinary one. >Rather, there are a bunch of unrelated subprograms that happen >to share a name and parameter profile, and a system invokes one >of those subprograms when a dispatching call is made to that >name and parameter profile. Certainly, there is no such thing as int type. There is only a bunch of unrelated numbers and a system places one or another in a memory cell according to signs of the zodiac. >> It is exactly not the case: >> >> class X >> { >> public : >> virtual void Foo () { printf ("X::Foo"); } >> virtual void Baz () { Foo (); } >> virtual ~X () { Baz (); } >> }; >> >> class Y : public X >> { >> public : >> virtual void Foo () { printf ("Y::Foo"); } >> }; >> >> void main () >> { >> Y A; >> >> A.Baz (); // dispatches to Y::Foo >> >> } // Y::~Y does not dispatch to Y::Foo >> >> This should print: >> >> Y::Foo >> X::Foo > >Why did you not also include in Y > virtual ~Y() { Baz(); } Because the above is enough to illustrate the point. 1. If this is a class-wide pointer then Baz() violates its contract when called from the destructor of Y. 2. If this is a specific pointer then Baz() violates the contract when called as A.Baz(). >From this immediately follows the proposition I started with, "this" is sometimes class-wide and sometimes specific. >Then you would see that it prints > Y::Foo > Y::Foo > X::Foo >showing that Y::~Y does first dispatch to Y::Foo. >You left out the case that demonstrates that I am correct. -- Regards, Dmitry Kazakov http://www.dmitry-kazakov.de