Issue 657: Chapter 4.3.3.8, Comments on DynAny (port-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: There are repeated references in the chapter to narrowing a DynAny to the desired type, but there is no standard narrowing mechanism defined in CORBA IDL. Editorials in para 5 and 8 also Resolution: fixed, close issue Revised Text: Actions taken: August 7, 1997: receivved issue June 25, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: 07 Aug 97 16:35:32 -0700 From: "JSPIRN.US.ORACLE.COM" To: issues@omg.org, port-rtf@omg.org Subject: Comments on DynAny for Portability RFP Cc: JTREZZO@us.oracle.com, DBROWER@us.oracle.com, KCOLEMAN@us.oracle.com The following issues concern the "Dynamic Any" in the portablility RFP submission. They were prepared by Kim Coleman of Oracle; I am forwarding them on in my capacity as a member of the portability RTF. Thanks, Jeff Spirn ================================= Date: 07 Aug 97 10:13:34 From:"KCOLEMAN.US.ORACLE.COM" To:jspirn Subject:Comments on DynAny for Portability Spec Cc:dbrower,tplambec,hspintzi,dlowe MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Comments on Chapter 4 (DynAny) of orbos/97-04-14 (Portability spec) .3.3.8 ------- There are repeated references here and elsewhere in the chapter to narrowing a DynAny to the desired type (such as DynStruct), but there is no standard narrowing mechanism defined in CORBA IDL. The C++ mapping supports such an operation on Object, but this is language mapping specific. Has the spec been changed in 2.1 to reflect a narrow operation? Paragraph 1: "The DynAny interface allows a client to iterate through the components of the struct data value pointed [to] by a DynStruct object." This rather implies iterators are only useful for struct values, but of course this is not true, as demonstrated by a later discussions. Paragraph 5 (editorial): "The programmer is able to inspect/initialize the a component..." ^^^^^ Paragraph 8: What is meant by "offset"? This is never defined. Offset from what? What's the unit of measure? I think we all understand what is meant here, but the usage tends to imply byte offsets into the value rather than an index into the value components. Parallelism with the old TypeCode param mechanism might lead to less confusion. Also, the components of the various flavors of DynAny are never explicitly defined. Something along the lines of the specification of TypeCode::param seems necessary. Return-Path: Sender: jon@sems.com Date: Fri, 08 Aug 1997 09:39:56 -0700 From: Jonathan Biggar Organization: Seagate Software, Network & Storage Management Group To: "JSPIRN.US.ORACLE.COM" Cc: issues@omg.org, port-rtf@omg.org, JTREZZO@us.oracle.com, DBROWER@us.oracle.com, KCOLEMAN@us.oracle.com Subject: Re: Comments on DynAny for Portability RFP References: <199708080659.XAA15448@mailsun2.us.oracle.com> My comments are integrated below: JSPIRN.US.ORACLE.COM wrote: > 4.3.3.8 > ------- > There are repeated references here and elsewhere in the chapter to > narrowing a DynAny to the desired type (such as DynStruct), but > there > is no standard narrowing mechanism defined in CORBA IDL. The C++ > mapping > supports such an operation on Object, but this is language mapping > specific. Has the spec been changed in 2.1 to reflect a narrow > operation? > All language bindings define a mechanism for narrowing, some more smoothly thanothers. For C++, the _narrow operations are defined. For languages like C where references are void *, or Smalltalk, no explicit narrowing is necessary. Return-Path: Date: 08 Aug 97 10:08:06 -0700 From: "KCOLEMAN.US.ORACLE.COM" To: jon@sems.com Subject: Re: Comments on DynAny for Portability RFP Cc: JSPIRN@us.oracle.com, dbrower@us.oracle.com, jtrezzo@us.oracle.com, port-rtf@omg.org X-Orcl-Application: In-Reply-To: UNX07.US.ORACLE.COM:jon@sems.com's message of 08-Aug-97 09:39 Jonathan Biggar writes: All language bindings define a mechanism for narrowing, some more smoothly thanothers. For C++, the _narrow operations are defined. For languages like C where references are void *, or Smalltalk, no explicit narrowing is necessary. I have to disagree about narrow and the C mapping. Because refs are void* in C, I can cast a string to a ref, too, but I'd hardly call that narrowing. Narrowing implies a certain degree of type safety to me that is not supported in the C mapping. Granted, this is probably more an issue for the general core rather than the portability spec, but if we're going to start writing specs which assuming support of narrowing, it seems we ought to get the concept into the core and out of the realm of the implied. ------------- Kim Coleman, kcoleman@us.oracle.com Oracle Media Net, Dist. Object Technology Group Oracle Corp., Redwood Shores, CA Date: 08 Aug 97 09:39:56 From:"Jonathan Biggar " To:JSPIRN.US.ORACLE.COM, Subject:Re: Comments on DynAny for Portability RFP Cc:issues@omg.org,port-rtf@omg.org,JTREZZO@us.oracle.com,DBROWER@us.oracle.com,KCOLEMAN@us.oracle.com Sender:jon@sems.com Organization:Seagate Software, Network & Storage Management Group X-Mailer:Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4m) References:<199708080659.XAA15448@mailsun2.us.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" My comments are integrated below: JSPIRN.US.ORACLE.COM wrote: > 4.3.3.8 > ------- > There are repeated references here and elsewhere in the chapter to > narrowing a DynAny to the desired type (such as DynStruct), but > there > is no standard narrowing mechanism defined in CORBA IDL. The C++ > mapping > supports such an operation on Object, but this is language mapping > specific. Has the spec been changed in 2.1 to reflect a narrow > operation? > All language bindings define a mechanism for narrowing, some more smoothly thanothers. For C++, the _narrow operations are defined. For languages like C where references are void *, or Smalltalk, no explicit narrowing is necessary. Return-Path: Sender: jon@sems.com Date: Fri, 08 Aug 1997 10:58:14 -0700 From: Jonathan Biggar Organization: Seagate Software, Network & Storage Management Group To: "KCOLEMAN.US.ORACLE.COM" Cc: jon@sems.com, JSPIRN@us.oracle.com, dbrower@us.oracle.com, jtrezzo@us.oracle.com, port-rtf@omg.org Subject: Re: Comments on DynAny for Portability RFP References: <199708081754.KAA14412@mailsun2.us.oracle.com> KCOLEMAN.US.ORACLE.COM wrote: > Jonathan Biggar writes: > > All language bindings define a mechanism for narrowing, some more smoothly > thanothers. For C++, the _narrow operations are > defined. For languages like C where > references are void *, or Smalltalk, no explicit narrowing is necessary. > > I have to disagree about narrow and the C mapping. Because refs are void* in > C, I can cast a string to a ref, too, but I'd hardly call that narrowing. > Narrowing implies a certain degree of type safety to me that is not supported > in the C mapping. > > Granted, this is probably more an issue for the general core rather than the > portability spec, but if we're going to start writing specs which assuming > support of narrowing, it seems we ought to get the concept into the core and > out of the realm of the implied. Well, I never said that the narrow was safe, just that it is possible and trivial (just reuse the same void * as the new object reference type). Jon Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Fri, 08 Aug 1997 15:55:33 -0400 To: "KCOLEMAN.US.ORACLE.COM" From: Steve Vinoski Subject: Re: Comments on DynAny for Portability RFP Cc: jon@sems.com, JSPIRN@us.oracle.com, dbrower@us.oracle.com, jtrezzo@us.oracle.com, port-rtf@omg.org At 10:08 AM 8/8/97 -0700, KCOLEMAN.US.ORACLE.COM wrote: >Jonathan Biggar writes: > > All language bindings define a mechanism for narrowing, some more smoothly > thanothers. For C++, the _narrow operations are > defined. For languages like C where > references are void *, or Smalltalk, no explicit narrowing is necessary. > >I have to disagree about narrow and the C mapping. Because refs are void* in >C, I can cast a string to a ref, too, but I'd hardly call that narrowing. >Narrowing implies a certain degree of type safety to me that is not supported >in the C mapping. Actually, all languages support narrowing because all languages must support the Object::is_a() operation. Some languages, such as C++, require further language-specific typecasting for their object references beyond is_a(), which is why we have narrow(). (Historically, it happened a little differently, however. The C++ _narrow() came before CORBA 2.0. Its introduction provided the impetus for the addition of a language-independent way to traverse an IDL inheritance hierarchy, hence the addition of the Object::is_a() operation into CORBA 2.0.) --steve Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 12 Aug 1997 10:55:35 +1000 (EST) From: Michi Henning To: port-rtf@omg.org, orbos@omg.org, ab@omg.org Subject: Portability spec and DynAny Hi, reading through the portability spec, I cannot find an easy way for a client or server to stringify a value of type DynAny. The ability to do this is important - for example, the current Trading Service spec obliges a trader to persistify values of type Any, but there is no portable way to do this it the current C++ mapping. The new portability spec fixes this, but at significant cost. Basically, I need to convert an Any to a DynAny using DynAny::from_any(), and then do a recursive descent parse of the DynAny to produce some stringified version of the value that I can write into a database. In effect, this forces me to create my own marshalling routines for IDL types of arbitrary complexity, and IDL types that are not known at compile time. My feeling is that this is far too much work to just get the value into a file and back out again. Developers will continously re-invent the wheel, and they will all come up with different and incompatible versions of the representation of an Any on disk. It would be far easier to add operations to DynAny which allow me to turn it into a string (or into a blob) and back again. That way, we'd have a standard and interoperable representation of an Any value. Also, adding this would solve most of the current difficulties of storing IDL values persistently. If DynAny provides a stringify operation, I can persistify arbitrary IDL values by simply injecting them into a DynAny and then persistifying the DynAny. I think a stringify for DynAny would add substantial value for developers. For the trading service, the feature is mandatory. If the portability spec does not add it, we will have to wait until the next incarnation of the POS comes along before we can build traders portably. Also, the need to store arbitrary values in files and to retrieve them again later will be important for a very large number of applications. To me, this means that at least basic functionality should be provided in the core, instead of relegating this to a service. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html