Issue 2262: Impl methods should be dispatchable (ada-rtf) Source: (, ) Nature: Enhancement Severity: Summary: Summary: I suggest that the IDL to Ada mapping standard specifically mention that Impl side methods be dispatching. In order to achieve this, the Impl package spec generated for an interface A should contain the marked declaration: with POA_A; package A.Impl is type Object is new POA_A.Object with private; -------- ADDITION : type Object_Access is access all Object"Class; -------- END OF ADDITION -- example method: procedure Meth (Self : access Object); end A.Impl; Resolution: Revised Text: Actions taken: December 16, 1998: received issue June 4, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: "Oliver M. Kellogg" To: Cc: Subject: ADA-RTF: Impl methods should be dispatchable Date: Wed, 16 Dec 1998 19:29:45 +0100 X-Msmail-Priority: Normal Issue type: Enhancement I suggest that the IDL to Ada mapping standard specifically mention that Impl side methods be dispatching. In order to achieve this, the Impl package spec generated for an interface A should contain the marked declaration: with POA_A; package A.Impl is type Object is new POA_A.Object with private; -------- ADDITION : type Object_Access is access all Object'Class; -------- END OF ADDITION -- example method: procedure Meth (Self : access Object); end A.Impl; The user is then free to define his own extensions, overriding the methods defined in A.Impl, for example with A.Impl; package Blimp is type Object is new A.Impl.Object with null record; procedure Meth (Self : access Object); end Blimp; By declaring a server side object as follows: The_Obj : A.Impl.Object_Access := new Blimp.Object; (and making this object known to the Object Adapter as appropriate), a client side invocation of method A.Meth dispatches to Blimp.Meth at the server side. -- A prototype implementation of the described mechanism is available upon request. -- Oliver M. Kellogg DaimlerChrysler Aerospace Sensor Systems, Dept. VE3SW5 D-89070 Ulm, Germany phone: (+49) 731 392-7138 fax: (+49) 731 392-4255 e-mail: Oliver.Kellogg@vs.dasa.de Return-Path: X-Sender: giddiv@gamma Date: Thu, 17 Dec 1998 11:06:59 -0500 To: "Oliver M. Kellogg" From: Victor Giddings Subject: Re: ADA-RTF: Impl methods should be dispatchable Cc: Just to get a jump on considering this issue: I am not sure how the proposed addition achieves the desired result. The declaration of the class-wide access type does not, in itself, require its use in the ORB's call from the object adapter to the Impl (servant). In fact, the ORB can achieve the desired behavior in a number of ways, including declaration of the class-wide access type in a non-visible location. So I'm not sure of the value of requiring this addition as part of the standard. I also note that this type of redispatching is not required in other language mappings. In fact, the C++ mapping precludes it. This doesn't necessarily make it a bad thing, but does bring into question if it is a necessary thing. At 07:29 PM 12/16/98 +0100, Oliver M. Kellogg wrote: >Issue type: Enhancement > >I suggest that the IDL to Ada mapping standard specifically >mention that Impl side methods be dispatching. In order to >achieve this, the Impl package spec generated for an >interface A should contain the marked declaration: > >with POA_A; >package A.Impl is > type Object is new POA_A.Object with private; > -------- ADDITION : > type Object_Access is access all Object'Class; > -------- END OF ADDITION > > -- example method: > procedure Meth (Self : access Object); > >end A.Impl; > >The user is then free to define his own extensions, >overriding the methods defined in A.Impl, for example > >with A.Impl; > >package Blimp is > > type Object is new A.Impl.Object with null record; > > procedure Meth (Self : access Object); > >end Blimp; > >By declaring a server side object as follows: > > The_Obj : A.Impl.Object_Access := new Blimp.Object; > >(and making this object known to the Object Adapter as >appropriate), a client side invocation of method A.Meth >dispatches to Blimp.Meth at the server side. > > >-- >A prototype implementation of the described mechanism >is available upon request. >-- >Oliver M. Kellogg >DaimlerChrysler Aerospace >Sensor Systems, Dept. VE3SW5 >D-89070 Ulm, Germany >phone: (+49) 731 392-7138 >fax: (+49) 731 392-4255 >e-mail: Oliver.Kellogg@vs.dasa.de > Victor Giddings Phone: 703-295-6500 Senior Product Engineer Fax: 703-295-6501 Objective Interface Systems victor.giddings@ois.com Return-Path: From: "Oliver M. Kellogg" To: "Victor Giddings" Cc: Subject: Re: ADA-RTF: Impl methods should be dispatchable Date: Fri, 18 Dec 1998 10:58:16 +0100 X-Msmail-Priority: Normal Victor Giddings wrote: > The > declaration of the class-wide access type does not, in itself, > require its > use in the ORB's call from the object adapter to the Impl (servant). Perhaps I was a little foggy on that. I had written: > >By declaring a server side object as follows: > > > > The_Obj : A.Impl.Object_Access := new Blimp.Object; > > > >(and making this object known to the Object Adapter as > >appropriate), a client side invocation of method A.Meth > >dispatches to Blimp.Meth at the server side. I was implying that the object adapter would then use the object passed to it, in this case The_Obj, for a dispatching call to Meth. > In > fact, the ORB can achieve the desired behavior in a number of ways, > including declaration of the class-wide access type in a non-visible > location. However, in that case the user cannot declare an access value of type A.Impl.Object_Access and have it point to different extensions of A.Impl.Object. > I also note that this type of redispatching is not required in other > language mappings. In fact, the C++ mapping precludes it. To my amazement, you are right. I guess I'll write a proposal to the C++ RTF to include "virtual" in the servant method mapping. I do realize that this proposal may entail user visible changes in mappings to non object-oriented languages (such as C.) > This doesn't > necessarily make it a bad thing, but does bring into question if it > is a > necessary thing. I have written a service where I require this feature. Of course this alone is not a justification -- I'm just saying that the idea was borne of a concrete need. -- O. Kellogg