Issue 10547: DLRL Issue: Int the future, allow DLRL valuetype implementations? (data-distribution-rtf) Source: OCI (Mr. Donald Busch, busch_d(at)ociweb.com) Nature: Uncategorized Issue Severity: Summary: The DLRL spec uses CORBA valuetypes to specify DLRL objects. The implementations of these CORBA valuetypes (e.g. Foo) are completely provided by the DLRL -- the user doesn't have to implement anything, which is great from a simplicity standpoint. However, this limits the DLRL valuetypes to being not much more that fancy structs with inheritance and relationships, but no behavior. One of the capabilities of standard CORBA valuetypes is the ability to specify valuetype operations in IDL and then implement them in the target language. The CORBA valuetype specification has permits the user to write the valuetype's implementation class, providing behavior for the methods specified in IDL. The user then implements a valuetype factory as a hook to create instances of the user-written valuetype implementation. I can see a similar comcept as useful to DLRL. It would probably be useful for a user to specify valuetype operations in DLRL IDL and implement them in the target language. One way to do this is to have the DLRL compiler generate a Foo class with a pure virtual method for each valuetype operation. The user inherits from it, implementing a MyFoo with implemntations of the pure virtual methods. We also need a factory; naturally, we'd use the FooHome. The generated FooHome would include a pure virtual "create()", or something like it, which the user would implement in a derived MyFooHome class to create instances of his MyFoo. Instead of creating a FooHome and registering it with the Cache, the user creates a MyFooHome and registers it with the Cache. The DLRL core uses the MyFooHome's overridden create() method to make new Foo handles (which are actually MyFoo handles, containing the user's behavior). There may be holes in this, but the basic idea is probably useful. It would permit a DLRL object model to be a full object model. Resolution: Revised Text: Actions taken: December 22, 2006: received issue Discussion: End of Annotations:===== il-OSG: iK6YR7gVM1kXHjsYq.f804rJsgpFxqYSY.T_dP0pZeBsQB6ajCcNmu0yRGoiG5wSeXjBtMDSkkqmvqBLi6ZfGgsWDHQeP3wSx3zpz0jYIqQe0zcT0Z32RwpwBdhqOOBvsHosinDkMmyf2Ro- Date: Fri, 22 Dec 2006 16:49:28 -0600 From: Don Busch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: issues@omg.org Subject: DDS 06-04-09, DLRL Issue: Int the future, allow DLRL valuetype implementations? The DLRL spec uses CORBA valuetypes to specify DLRL objects. The implementations of these CORBA valuetypes (e.g. Foo) are completely provided by the DLRL -- the user doesn't have to implement anything, which is great from a simplicity standpoint. However, this limits the DLRL valuetypes to being not much more that fancy structs with inheritance and relationships, but no behavior. One of the capabilities of standard CORBA valuetypes is the ability to specify valuetype operations in IDL and then implement them in the target language. The CORBA valuetype specification has permits the user to write the valuetype's implementation class, providing behavior for the methods specified in IDL. The user then implements a valuetype factory as a hook to create instances of the user-written valuetype implementation. I can see a similar comcept as useful to DLRL. It would probably be useful for a user to specify valuetype operations in DLRL IDL and implement them in the target language. One way to do this is to have the DLRL compiler generate a Foo class with a pure virtual method for each valuetype operation. The user inherits from it, implementing a MyFoo with implemntations of the pure virtual methods. We also need a factory; naturally, we'd use the FooHome. The generated FooHome would include a pure virtual "create()", or something like it, which the user would implement in a derived MyFooHome class to create instances of his MyFoo. Instead of creating a FooHome and registering it with the Cache, the user creates a MyFooHome and registers it with the Cache. The DLRL core uses the MyFooHome's overridden create() method to make new Foo handles (which are actually MyFoo handles, containing the user's behavior). There may be holes in this, but the basic idea is probably useful. It would permit a DLRL object model to be a full object model. -Don Busch -- ---------------------------------------------------------------- Don Busch, Principal Software Engineer and Partner Object Computing, Inc. (OCI) http://www.ociweb.com http://www.theaceorb.com http://jacorb.ociweb.com "Never let what you can't do get in the way of what you can do." - John Wooden X-YMail-OSG: YM9Xu4IVM1krof0vKOPSOFwiUz8H.zt6K2HFbZ56BhYmERt2y1f.rzQPtcMi2gV84wqMeLTOxZOe6FhjvhIEHSx8oMnBYrSdPwNNBT6ZhneyKHJnJjs- Date: Wed, 09 May 2007 13:20:37 -0500 From: Don Busch User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) To: data-distribution-rtf@omg.org Subject: [Issue 10547] This is probably something that can be postponed to the future, as we have more pressing issues. -- ---------------------------------------------------------------- Don Busch, Principal Software Engineer and Partner Object Computing, Inc. (OCI) http://www.ociweb.com http://www.theaceorb.com http://jacorb.ociweb.com "Never let what you can't do get in the way of what you can do." - John Wooden ---------------------------------------------------------------- X-Server-Uuid: 0764DD54-627B-4C45-B37D-789FBDEDA467 Subject: RE: [Issue 10547] Date: Thu, 10 May 2007 02:55:26 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Issue 10547] thread-index: AceSZr+YDTJTZZXsSXOorNC2/MyrAQAaIQAA From: "Emiel.Schuurman" To: "Don Busch" , data-distribution-rtf@omg.org X-OriginalArrivalTime: 10 May 2007 06:55:58.0095 (UTC) FILETIME=[4328D1F0:01C792D0] X-WSS-ID: 6A5C1E773F8635136-03-01 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l4A6sKns020553 Hi, Actually we (prismtech) would like discuss this idea for the coming spec and possibly incorporate it. We especially like the addition of a sort of 'create' operation in the generated FooHome which the user can then override. We'd just to like add to the solution that default behavior is provided to create a normal Foo object, so applications arent forced to override anything. But we agree this issue is not that urgent in any way, but a solution for this issue shouldn't take much time. Kind regards, Emiel Schuurman -----Original Message----- From: Don Busch [mailto:buschd@ociweb.com] Sent: Wednesday, May 09, 2007 8:21 PM To: data-distribution-rtf@omg.org Subject: [Issue 10547] This is probably something that can be postponed to the future, as we have more pressing issues. -- ---------------------------------------------------------------- Don Busch, Principal Software Engineer and Partner Object Computing, Inc. (OCI) http://www.ociweb.com http://www.theaceorb.com http://jacorb.ociweb.com "Never let what you can't do get in the way of what you can do." - John Wooden ----------------------------------------------------------------