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,7a180be12347b9d3 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,7a180be12347b9d3 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2002-02-07 17:01:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Matthew Heaney" Newsgroups: comp.lang.ada,comp.object Subject: Re: Merits of re-dispatching [LONG] Date: Thu, 7 Feb 2002 20:06:42 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3c62524f.93369796@News.CIS.DFN.DE> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:19741 comp.object:33617 Date: 2002-02-07T20:06:42-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:3c62524f.93369796@News.CIS.DFN.DE... > procedure Finalize (Object : in out A) is > begin > Foo (A'Class (Object)); -- Re-dispatch to the child's Foo > end Finalize; > > When A is finalized as a part of AA, it re-dispatches to AA.Foo, which > may access already finalized parts of AA! A user of A has no way to > learn the problem from the specification of A. He must look into the > implementation of A.Finalize. The same is valid for Initialize as > well. Actually it is a common error among fresh baked C++ programmers > to call virtual functions (dispatch) from constructors. Yes, but in Ada95, operations are static by default. You have to take active steps in order to force the dispatching to occur. So the scenario you describe cannot happen accidently. This is not the case in C++, where virtual member functions called through a reference or pointer automatically dispatch. So yes you can very easily have the problem you cite in C++. (Which is why many C++ books point out this feature of the language.) > Though merits of re-dispatching seem to me suspicious, it is easy to > implement it without casting. Let we really want object's IDENTITY, > i.e. objects which always "know" their actual type. Ada 95 perfectly > supports this without any casting! > > package Self_Identifying is > type A is new > Ada.Finalization.Limited_Controlled with private; > type A_Ptr is access all A'Class; > procedure Finalize (Object : in out A); > procedure Foo (Object : in out A); > private > type A is new > Ada.Finalization.Limited_Controlled with > record > Self : A_Ptr := A'Unchecked_Access; -- Class wide self-reference > end record; > end Self_Identifying; This is a horrible way to do this. Don't use a named access type when an access discriminant will do: type Handle_Type (O : access A'Class) is limited null record; type A is new Limited_Controlled with record H : Handle_Type (A'Access); end record; > Is there examples where re-dispatching is really unavoidable? There is a very simple solution to your problem: don't do it.