From: Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
Subject: Re: Question about OO programming in Ada
Date: Wed, 10 Dec 2003 18:15:36 +0100
Date: 2003-12-10T18:15:36+01:00 [thread overview]
Message-ID: <ukjetv076agj4vto7opa3b617unhhdcbao@4ax.com> (raw)
In-Reply-To: 1071070064.52023@master.nyc.kbcfp.com
On Wed, 10 Dec 2003 10:27:43 -0500, Hyman Rosen <hyrosen@mail.com>
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
next prev parent reply other threads:[~2003-12-10 17:15 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 19:04 Question about OO programming in Ada Ekkehard Morgenstern
2003-11-25 20:17 ` Randy Brukardt
2003-11-26 0:34 ` Ekkehard Morgenstern
2003-11-26 6:17 ` Vinzent 'Gadget' Hoefler
2003-11-26 9:29 ` Dmitry A. Kazakov
2003-11-26 15:54 ` Stephen Leake
2003-11-26 20:07 ` Randy Brukardt
2003-11-26 21:36 ` Stephen Leake
2003-11-26 8:56 ` Peter Hermann
2003-11-25 20:55 ` Martin Krischik
2003-11-26 0:22 ` Ekkehard Morgenstern
2003-11-26 1:00 ` Jeffrey Carter
2003-11-26 16:36 ` Martin Krischik
2003-11-26 18:09 ` Robert I. Eachus
2003-11-27 13:45 ` Jean-Pierre Rosen
2003-11-25 21:48 ` Stephen Leake
2003-11-26 0:01 ` Ekkehard Morgenstern
2003-11-26 1:16 ` Jeffrey Carter
2003-11-26 15:10 ` Georg Bauhaus
2003-11-26 15:48 ` Stephen Leake
2003-11-26 16:24 ` Hyman Rosen
2003-11-26 17:58 ` Robert I. Eachus
2003-11-27 2:10 ` Ekkehard Morgenstern
2003-11-27 10:15 ` Ludovic Brenta
2003-11-27 18:35 ` Jeffrey Carter
2003-11-28 4:35 ` Hyman Rosen
2003-11-28 7:28 ` Vinzent 'Gadget' Hoefler
2003-11-28 8:46 ` Dale Stanbrough
2003-11-28 10:16 ` Vinzent 'Gadget' Hoefler
2003-12-01 15:57 ` Martin Krischik
2003-12-01 16:47 ` Hyman Rosen
2003-12-03 18:35 ` Martin Krischik
2003-12-01 21:13 ` Jeffrey Carter
2003-12-02 8:47 ` Dmitry A. Kazakov
2003-12-03 9:29 ` Pascal Obry
2003-12-03 11:26 ` Dmitry A. Kazakov
2003-12-03 12:49 ` Ludovic Brenta
2003-12-03 13:41 ` Dmitry A. Kazakov
2003-12-03 14:11 ` Ludovic Brenta
2003-12-03 14:45 ` Dmitry A. Kazakov
2003-12-03 15:44 ` Hyman Rosen
2003-12-03 16:11 ` Dmitry A. Kazakov
2003-12-03 18:20 ` David C. Hoos
[not found] ` <28eb01c3b9ca$25b18870$b101a8c0@sy.com>
2003-12-03 18:35 ` Hyman Rosen
2003-12-03 20:05 ` Randy Brukardt
2003-12-03 20:57 ` Hyman Rosen
2003-12-03 21:16 ` Hyman Rosen
2003-12-03 22:04 ` Pascal Obry
2003-12-03 22:34 ` Hyman Rosen
2003-12-04 1:23 ` Robert I. Eachus
2003-12-04 7:15 ` Hyman Rosen
2003-12-04 17:43 ` Warren W. Gay VE3WWG
2003-12-04 8:55 ` Dmitry A. Kazakov
2003-12-04 19:13 ` Randy Brukardt
2003-12-04 19:29 ` Hyman Rosen
2003-12-04 21:32 ` Robert I. Eachus
2003-12-05 8:43 ` Dmitry A. Kazakov
2003-11-27 22:12 ` Robert I. Eachus
2003-11-28 6:37 ` Simon Wright
2003-11-30 2:51 ` Robert I. Eachus
2003-12-06 7:48 ` Chad Bremmon
2003-12-06 13:33 ` Jeff C,
2003-12-06 22:44 ` Hyman Rosen
2003-12-07 3:02 ` Chad Bremmon
2003-12-07 7:53 ` Hyman Rosen
2003-12-07 15:34 ` James Rogers
2003-12-07 18:30 ` Martin Krischik
2003-12-07 20:25 ` James Rogers
2003-12-08 3:36 ` Hyman Rosen
2003-12-08 4:42 ` Chad Bremmon
2003-12-08 8:42 ` Hyman Rosen
2003-12-08 9:34 ` Dmitry A. Kazakov
2003-12-08 13:25 ` Hyman Rosen
2003-12-08 15:05 ` Dmitry A. Kazakov
2003-12-09 4:38 ` Hyman Rosen
2003-12-09 8:19 ` Dmitry A. Kazakov
2003-12-09 13:29 ` Hyman Rosen
2003-12-09 14:36 ` Dmitry A. Kazakov
2003-12-09 15:05 ` Hyman Rosen
2003-12-09 15:59 ` Dmitry A. Kazakov
2003-12-09 16:41 ` Hyman Rosen
2003-12-10 11:32 ` Dmitry A. Kazakov
2003-12-10 15:27 ` Hyman Rosen
2003-12-10 17:15 ` Dmitry A. Kazakov [this message]
2003-12-08 17:55 ` Chad Bremmon
2003-12-08 23:09 ` Hyman Rosen
2003-12-09 8:26 ` Dmitry A. Kazakov
2003-12-08 19:33 ` Martin Krischik
2003-12-09 4:41 ` Hyman Rosen
2003-12-08 17:27 ` Chad Bremmon
2003-12-08 18:44 ` Georg Bauhaus
2003-12-08 19:27 ` Martin Krischik
2003-12-08 19:36 ` Chad Bremmon
2003-12-09 4:43 ` Hyman Rosen
2003-12-08 23:23 ` Hyman Rosen
2003-12-08 19:25 ` Martin Krischik
2003-12-07 21:29 ` Peter C. Chapin
2003-12-08 3:44 ` Hyman Rosen
2003-12-08 3:46 ` Hyman Rosen
2003-12-08 5:54 ` James Rogers
2003-12-08 8:45 ` Hyman Rosen
2003-12-07 17:39 ` Chad Bremmon
2003-12-08 23:39 ` Hyman Rosen
2003-12-09 2:36 ` Chad Bremmon
2003-12-09 4:52 ` Hyman Rosen
2003-12-09 11:24 ` Georg Bauhaus
2003-12-09 18:42 ` Chad Bremmon
2003-12-09 20:11 ` Hyman Rosen
2003-12-08 23:40 ` Hyman Rosen
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox