comp.lang.ada
 help / color / mirror / Atom feed
From: Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
Subject: Re: abstract sub programs overriding
Date: Thu, 11 Mar 2004 11:09:50 +0100
Date: 2004-03-11T11:09:50+01:00	[thread overview]
Message-ID: <at8050lmd96obnra145knv84niav1ebfrs@4ax.com> (raw)
In-Reply-To: 1078924150.268074@master.nyc.kbcfp.com

On Wed, 10 Mar 2004 08:08:56 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> To allow /= to force. To re-dispatch in Ada you have do it expilictly
>> by converting the object of a specific type to a class-wide. This is
>> way different (though also problematic) from inconsistent attempts in
>> C++ to view the same thing as both specific and class-wide. This
>> cannot be reconciled.
>
>In C++ you can also choose whether to dispatch or not, but the default
>is to dispatch. If you want to call a function of a particular class,
>you just specify that (eg., Mumble::Foo()) and you get it.

To dispatch vs. not has to be defined by solely the object type. This
is the only right way, IMO, and Ada conforms to it.

>Remember,
>Ada compilers still use a vtable pointer inside each object, not the
>way you would have it, a two-part object/vtable fat pointer.

That tags are embedded in Ada is a consequence of a desire to have
re-dispatch and more generally to have objects with identity. Though
as practice shown it was not needed, because the Rosen trick does the
same and has the advantage of explicit indication that identity is
indeed relevant. However the Ada concept of specific and class-wide
types as different types is one of rare real advances in that swamp
called OO. And yes, the concept could be used for non-tagged types
having the best of both worlds.

>> Huh. So the common point of view is that dispatching on unconstructed
>> objects is good?
>
>As I said, not in C++. But much fuss has been made of claiming that
>C++'s way of dispatching in *tors is "confusing" and there are also
>people who want constructors to be able to easily condition their
>behavior based on the complete type of the object. So Java, and Ada
>too, I suppose, do a two-step initialization. The bits of the object
>are perhaps set to something marginally non-random (in Java it's all
>bits zero; you describe what Ada does below) and then methods are on
>their own to worry about whether things are ready to be used.
>
>> Note also that in Ada it cannot happen.
>
>Really? What if you have a hierarchical class where each base has its
>own Initialize? Is each version responsible for calling the version of
>its base?

Yes, but Initialize is not a constructor in C++ sense. When Ada will
have [first stage] constructors that responsibility will become one of
the compiler.

>What is to keep a base version from converting to classwide
>type and calling a dispatching method which will try to use an unset
>member of the derived class (eg., a file not yet opened)?

That will be difficult to achieve with controlled types because they
have *reverse* order of calls to Initialize, but I understand the
question.

When objects are constructed in two stages, the first stage makes some
basic initialization in a way that a base knows nothing about
children. This initialization *cannot* be overriden by children, only
extended. C++ tries to be conform with that, but it has an unsolvable
problems of its messing with specific vs. class-wide. At this stage no
dispatch is needed and no surprises to expect. This exists in Ada, but
it is not user-definable, yet. The second stage construction can be
made class-wide, so that a base could dispatch from its constructor to
child methods. Note that this construction should be made in a reverse
order - children first, exactly as Initialize in Ada works. That makes
dispatch in base's Initialize safe. To summarize:

1. The first stage constructs a *specific* instance of a Derived_Type,
descendant of Type, out of a raw memory chunk. It creates an object of
the type Derived_Type, but that might be not a valid instance of
Type'Class. This makes

2. the second stage by constructing Type'Class out of Derived_Type.

Returning to your example, if Type is an abstract type, and
Derived_Type has to have File, accessed by Type via some dispatching
method, then File (a handle to) has to be initialized and opened at
the stage one, and the class-wide constructor of Type may safely use
it at the stage two.

IMO Ada model is very close to that.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de



  parent reply	other threads:[~2004-03-11 10:09 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-02 19:01 abstract sub programs overriding Evangelista Sami
2004-03-03  1:43 ` Stephen Leake
2004-03-05 15:02   ` Evangelista Sami
2004-03-05 16:15     ` Marius Amado Alves
2004-03-08 18:54       ` Adam Beneschan
2004-03-08 23:42         ` Marius Amado Alves
2004-03-05 16:26     ` Marius Amado Alves
2004-03-06  9:31       ` Simon Wright
2004-03-06 15:18         ` Evangelista Sami
2004-03-06 19:09           ` Marius Amado Alves
2004-03-07 12:35             ` Simon Wright
2004-03-07 13:39               ` Marius Amado Alves
2004-03-08 19:08               ` Adam Beneschan
2004-03-08 20:03                 ` Hyman Rosen
2004-03-09  8:51                   ` Dmitry A. Kazakov
2004-03-09 13:34                     ` Hyman Rosen
2004-03-09 14:49                       ` Dmitry A. Kazakov
2004-03-09 15:14                         ` Hyman Rosen
2004-03-09 15:56                           ` Dmitry A. Kazakov
2004-03-09 16:32                             ` Hyman Rosen
2004-03-10  9:32                               ` Dmitry A. Kazakov
2004-03-10 13:08                                 ` Hyman Rosen
2004-03-10 14:58                                   ` Robert I. Eachus
2004-03-10 16:00                                     ` Hyman Rosen
2004-03-10 18:07                                       ` Robert I. Eachus
2004-03-10 20:04                                         ` Hyman Rosen
2004-03-11  2:43                                           ` Robert I. Eachus
2004-03-11 13:55                                             ` Hyman Rosen
2004-03-12 23:02                                               ` Robert I. Eachus
2004-03-14 21:33                                                 ` Hyman Rosen
2004-03-15  5:59                                                   ` Robert I. Eachus
2004-03-15 14:39                                                     ` Hyman Rosen
2004-03-16 16:16                                                       ` Robert I. Eachus
2004-03-16 16:51                                                         ` Hyman Rosen
2004-03-16 19:54                                                         ` Hyman Rosen
2004-03-16 23:16                                                           ` Randy Brukardt
2004-03-17  1:54                                                           ` Robert I. Eachus
2004-03-16 23:14                                                         ` Randy Brukardt
2004-03-17  2:43                                                           ` Robert I. Eachus
2004-03-17 17:40                                                             ` Randy Brukardt
2004-03-18  2:39                                                               ` Robert I. Eachus
2004-03-18  5:57                                                                 ` Randy Brukardt
2004-03-18 15:03                                                                   ` Hyman Rosen
2004-03-18 20:32                                                                     ` Randy Brukardt
2004-03-19  3:59                                                                       ` Hyman Rosen
2004-03-19 19:37                                                                         ` Randy Brukardt
2004-03-16  6:00                                               ` Randy Brukardt
2004-03-11 10:09                                   ` Dmitry A. Kazakov [this message]
2004-03-11 14:10                                     ` Hyman Rosen
2004-03-11 14:59                                       ` Dmitry A. Kazakov
2004-03-11 15:40                                         ` Hyman Rosen
2004-03-11 16:28                                           ` Dmitry A. Kazakov
2004-03-11 17:26                                             ` Hyman Rosen
2004-03-12  8:53                                               ` Dmitry A. Kazakov
2004-03-12 13:09                                                 ` Hyman Rosen
2004-03-12 14:00                                                   ` Dmitry A. Kazakov
2004-03-12 14:56                                                     ` Hyman Rosen
2004-03-12 18:19                                                       ` Dmitry A. Kazakov
2004-03-12 18:34                                                         ` Hyman Rosen
2004-03-12 20:05                                                           ` Georg Bauhaus
2004-03-13 10:12                                                           ` Dmitry A. Kazakov
2004-03-12 18:07                                               ` Robert I. Eachus
2004-03-10 15:51                 ` Evangelista Sami
2004-03-11  1:38                   ` Dan Eilers
2004-03-06 23:20     ` Dan Eilers
2004-03-03 12:00 ` Marius Amado Alves
2004-03-13  7:51 ` Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox