Issue 3159: null & void TCs and DynAny (orb_revision) Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com) Nature: Uncategorized Issue Severity: Summary: The DynAny chapter says nothing about whether DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly handle a TypeCode argument that has a TCKind of either tk_null or tk_void. I assume these are valid argument TypeCodes that do not result in an InconsistentTypeCode exception, and the returned DynAny is simply one that fulfills the basic DynAny interface and has no components. However, it would be nice to explicitly document the cases for these two TypeCodes, though, given that they're a little different from other TypeCodes in that they can't have any associated values. Resolution: Clarify with additional text as shown below Revised Text: With reference to ptc/99-12-07 Insert the following paragraph at the bottom of page 9-9, immediately following the new paragraph added by Core RTF 2k: "Creation of DynAnys with TCKind tk_null and tk_void is legal and results in the creation of a DynAny without a value and with zero components." Actions taken: December 21, 1999: received issue October 6, 2000: Incorporate changes and close issue Discussion: End of Annotations:===== X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 21 Dec 1999 14:15:08 -0500 To: issues@omg.org, orb_revision@omg.org From: Steve Vinoski Subject: null & void TCs and DynAny Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 9=~e9W)md9/g_d9;dkd9 The DynAny chapter says nothing about whether DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly handle a TypeCode argument that has a TCKind of either tk_null or tk_void. I assume these are valid argument TypeCodes that do not result in an InconsistentTypeCode exception, and the returned DynAny is simply one that fulfills the basic DynAny interface and has no components. However, it would be nice to explicitly document the cases for these two TypeCodes, though, given that they're a little different from other TypeCodes in that they can't have any associated values. --steve Date: Wed, 22 Dec 1999 07:15:57 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: Core Revision Task Force Subject: Re: null & void TCs and DynAny In-Reply-To: <4.1.19991221140937.00d23ba0@mail.boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?n0!!!=g!!-Ekd97_Td9 On Tue, 21 Dec 1999, Steve Vinoski wrote: > The DynAny chapter says nothing about whether > DynAnyFactory::create_dyn_any_from_type_code is supposed to > correctly > handle a TypeCode argument that has a TCKind of either tk_null or > tk_void. > > I assume these are valid argument TypeCodes that do not result in an > InconsistentTypeCode exception, and the returned DynAny is simply > one that > fulfills the basic DynAny interface and has no components. In the absence of words to the contrary, these are legal. > However, it > would be nice to explicitly document the cases for these two > TypeCodes, > though, given that they're a little different from other TypeCodes > in that > they can't have any associated values. Yes, that sounds sensible. How about: Append the following text at the bottom of page 9-8: Creation of DynAnys with TCKind tk_null and tk_void is legal and results in the creation of a DynAny without a value and zero components. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 21 Dec 1999 18:14:42 -0500 To: Michi Henning From: Steve Vinoski Subject: Re: null & void TCs and DynAny Cc: Core Revision Task Force In-Reply-To: References: <4.1.19991221140937.00d23ba0@mail.boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: UUT!!~#8!!M>f!!FJT!! At 07:15 AM 12/22/99 +1000, Michi Henning wrote: >How about: > >Append the following text at the bottom of page 9-8: > > Creation of DynAnys with TCKind tk_null and tk_void is legal and > results in the creation of a DynAny without a value and zero > components. That should do it. thanks, --steve Date: Thu, 17 Feb 2000 15:31:08 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 3159 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5h8e9?*Xd9Nf3e9f!@e9 Proposed resolution for this issue as suggested by Michi and massaged a little by me is: Summary: The DynAny chapter says nothing about whether DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly handle a TypeCode argument that has a TCKind of either tk_null or tk_void. I assume these are valid argument TypeCodes that do not result in an InconsistentTypeCode exception, and the returned DynAny is simply one that fulfills the basic DynAny interface and has no components. However, it would be nice to explicitly document the cases for these two TypeCodes, though, given that they're a little different from other TypeCodes in that they can't have any associated values. Resolution: Clarify with additional text as shown below Revised Text: With reference to ptc/99-12-07 Insert the following paragraph at the bottom of page 9-9, immediately following the new paragraph added by Core RTF 2k: "Creation of DynAnys with TCKind tk_null and tk_void is legal and results in the creation of a DynAny without a value and with zero components." _______________________________________________________ If this looks OK, I'd like to place it on the vote that goes out coming Monday. Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA.