Issue 3258: Can native be used in constructed IDL types? (orb_revision) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: CORBA 2.3.1, section 3.10.5 says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." This is ambiguous as to whether a native type may be used in a constructed IDL type that is intended to be used only locally: // IDL native MyNative; struct MyStruct { MyNative a_native; }; So, should the first sentence in 3.10.5 be read to mean that native may ONLY be used in parameters & results? If so, we ought to put the word "only" in there. Resolution: Incorporate changes and close issue. Revised Text: This is done by changing the two sentences in CORBA 2.3.1 section 3.10.5 that says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." to read: "A native type may be used only to define operation parameters and results. Native type parameters are permitted only in operations of local interfaces or valuetypes." Actions taken: January 26, 2000: received issue February 27, 2001: closed issue Discussion: While the second sentence in the quoted text from 2.3.1 section 3.10.5 alludes to using natives in constructed types, trying to generalize its use in general structs etc adds considerable complexity to marshaling time checking etc. So native should not be allowed anywhere else other than as parameter or return value type sepecification unless of course a very pressing use case is found for allowing it. Since we have not seen such a use case yet, it is prposed that native be restricted to specifying parameter types only. End of Annotations:===== sender<: jbiggar@corvette.floorboard.com Message-ID: <388F77C2.782A7F5@floorboard.com> Date: Wed, 26 Jan 2000 14:40:02 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, orb_revision@omg.org Subject: Can native be used in constructed IDL types? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: C]:!!kF5e9%29!![]\d9 CORBA 2.3.1, section 3.10.5 says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." This is ambiguous as to whether a native type may be used in a constructed IDL type that is intended to be used only locally: // IDL native MyNative; struct MyStruct { MyNative a_native; }; So, should the first sentence in 3.10.5 be read to mean that native may ONLY be used in parameters & results? If so, we ought to put the word "only" in there. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 28 Sep 2000 16:41:59 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 3258 proposed resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: VOjd9'ZQd9\:$"!(#~!! Issue 3258: Can native be used in constructed IDL types? (orb_revision) Click here for this issue's archive. Source: Floorboard Software (Jonathan Biggar jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: CORBA 2.3.1, section 3.10.5 says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." This is ambiguous as to whether a native type may be used in a constructed IDL type that is intended to be used only locally: // IDL native MyNative; struct MyStruct { MyNative a_native; }; So, should the first sentence in 3.10.5 be read to mean that native may ONLY be used in parameters & results? If so, we ought to put the word "only" in there. Proposed resolution: While the second sentence in the quoted text from 2.3.1 section 3.10.5 alludes to using natives in constructed types, trying to generalize its use in general structs etc adds considerable complexity to marshaling time checking etc. So native should not be allowed anywhere else other than as parameter or return value type sepecification unless of course a very pressing use case is found for allowing it. Since we have not seen such a use case yet, it is prposed that native be restricted to specifying parameter types only. This is done by changing the two sentences in CORBA 2.3.1 section 3.10.5 that says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." to read: "A native type may only be used to define operation parameters and results. Native type parameters are not permitted in operations in interfaces that are not local." Comments? Thanks, Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Reply-To: From: "Nick Sharman" To: , Subject: RE: Issue 3258 proposed resolution Date: Fri, 29 Sep 2000 13:56:15 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <39D3AD16.5CFE366@fpk.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =m3!!"5gd9GUad9)*,!! Jishnu, > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Proposed resolution: > > While the second sentence in the quoted text from 2.3.1 section >3.10.5 > alludes to using natives in constructed types, trying to generalize >its > use in general structs etc adds considerable complexity to >marshaling > time checking etc. So native should not be allowed anywhere else >other > than as parameter or return value type sepecification unless of >course a > very pressing use case is found for allowing it. Since we have not >seen > such a use case yet, it is prposed that native be restricted to > specifying parameter types only. This is done by changing the two > sentences in CORBA 2.3.1 section 3.10.5 that says: > > "A native type may be used to define operation parameters and >results. > However, there is no requirement that values of the type be >permitted in > remote invocations, either directly or as a component of a >constructed > type." > > to read: > > "A native type may only be used to define operation parameters and > results. > Native type parameters are not permitted in operations in interfaces > that are not local." > > Comments? > > Thanks, > > Jishnu. > -- > Jishnu Mukerji > Senior Systems Architect, EIAL > Hewlett-Packard Company > 300 Campus Drive, MS 2E-62 > Florham Park NJ 07932, USA > +1 973 443 7528 > jis@fpk.hp.com Interfaces marked as "local" (in the CORBA 3.0 changes) will also be subject to similar constraints, so it would be nice if they were identical. Has the Components FTF drafted anything in this area yet? The PI spec doesn't define any structs etc containing local interfaces, so I guess we could extend your hard-line rule for natives to local interfaces too (except that local interfaces can be base types). How about: Native types may only be used as attribute types, operation result types and operation paramreter types on local interfaces. Local interface types may only be used as base types of other local interfaces, and as attribute types, operation result types and operation parameter types on local interfaces. Of course, 2.n doesn't support the "local", and it's object instances that are locally constrained. If we do want to be more permissive, we can either define and use a 'localized' property as follows: Local interface types and native types are said to be 'localized' types. Any constructed type that contains a field of a 'localized' type is also 'localized'. Any array or sequence type whose element type is a 'localized' type is also 'localized'. A non-local interface cannot specify any attributes of 'localized' types, or any operation with a 'localized' result type or parameter type(s), or that raises any 'localized' exception types. Or alternatively, we could force the IDL author to enter a parallel universe of ecplicitly-local types : local struct MyStruct { native stuff; }; Which is similar to requiring interfaces derived from local interfaces themselves being marked "local". Regards Nick Date: Fri, 29 Sep 2000 14:44:16 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: <39D4ADCB.3E3991D@iona.com> <39D4C3B7.E9C6BBD2@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !3T!!~;Ke9?^#e9nB\d9 Jonathan Biggar wrote: > > Bob Kukura wrote: > > > > The following bullet from orbos/99-07-01, section 11.1.1, page 11-380 > > pretty clearly indicates that types constructed using local interfaces > > are possible, and are themselves locality constrained. > > > > * A local interface is a local type, as is any non-interface type > > declaration constructed > > using a local interface or other local type. For example, a struct, > > union, or > > exception with a member that is a local interface is also itself a > > local type. > > > > Maybe we should work native into this set of rules, describining it also > > as a "local type". > > I don't agree. Local interfaces follow all of the language mapping > rules for normal interface types as far as embedding in other structured > types. Each native types must have explicit rules defined in each > language mapping, That is correct. > and the amount of work to define the rules for > embedding each native in a struct, union, sequence, array, > valuetype, > etc is too much, and will only make it harder to keep the language > mappings up to date with the core. That would be an important consideration. Anyway, a proposed resolution covering either approach is now available in the archive. If discussion does not lead to any obvious consensus in a couple of weeks, we will use the tried and tested method of voting to selct one. How does that sound? Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Sat, 30 Sep 2000 07:34:11 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution In-Reply-To: <39D4B740.82260146@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 31Qd9V@G!!T/B!!o6&e9 On Fri, 29 Sep 2000, Jishnu Mukerji wrote: > "A native type, like a local interface, is a local type, as is any > non-interface type declaration constructed using a native or other > local type. For example, a struct, union, or exception with a > member > that is a native is also itself a local type. As such all rules > that > are enumerated for local types in section 3.7.6 "Local Interfaces" > apply to native type. In particular, any attempt to marshal a > native > type shall result in a MARSHAL standard system exception with > standard > minor code 2." > > This just incorporates the properties of local types by reference to > the > description in the local interfaces section and then highlights > those > aspects that are of particular importance to native types. > > > Further comments? I like that one! Cheers, Michi. Date: Fri, 29 Sep 2000 10:57:15 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: nick.sharman@cp.net CC: jis@fpk.hp.com, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 6,jd9:p#!!A,H!!"Lb!! The following bullet from orbos/99-07-01, section 11.1.1, page 11-380 pretty clearly indicates that types constructed using local interfaces are possible, and are themselves locality constrained. A local interface is a local type, as is any non-interface type declaration constructed using a local interface or other local type. For example, a struct, union, or exception with a member that is a local interface is also itself a local type. Maybe we should work native into this set of rules, describining it also as a "local type". -Bob Nick Sharman wrote: > > Jishnu, > > > -----Original Message----- > > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > > > Proposed resolution: > > > > While the second sentence in the quoted text from 2.3.1 section 3.10.5 > > alludes to using natives in constructed types, trying to generalize its > > use in general structs etc adds considerable complexity to marshaling > > time checking etc. So native should not be allowed anywhere else other > > than as parameter or return value type sepecification unless of course a > > very pressing use case is found for allowing it. Since we have not seen > > such a use case yet, it is prposed that native be restricted to > > specifying parameter types only. This is done by changing the two > > sentences in CORBA 2.3.1 section 3.10.5 that says: > > > > "A native type may be used to define operation parameters and results. > > However, there is no requirement that values of the type be permitted in > > remote invocations, either directly or as a component of a constructed > > type." > > > > to read: > > > > "A native type may only be used to define operation parameters and > > results. > > Native type parameters are not permitted in operations in interfaces > > that are not local." > > > > Comments? > > > > Thanks, > > > > Jishnu. > > -- > > Jishnu Mukerji > > Senior Systems Architect, EIAL > > Hewlett-Packard Company > > 300 Campus Drive, MS 2E-62 > > Florham Park NJ 07932, USA > > +1 973 443 7528 > > jis@fpk.hp.com > > Interfaces marked as "local" (in the CORBA 3.0 changes) will also be subject > to similar constraints, so it would be nice if they were identical. Has the > Components FTF drafted anything in this area yet? > > The PI spec doesn't define any structs etc containing local interfaces, so I > guess we could extend your hard-line rule for natives to local interfaces > too (except that local interfaces can be base types). How about: > > Native types may only be used as attribute types, operation > result types and operation paramreter types on local interfaces. > > Local interface types may only be used as base types of other > local interfaces, and as attribute types, operation result types > and operation parameter types on local interfaces. > > Of course, 2.n doesn't support the "local", and it's object instances that > are locally constrained. > > If we do want to be more permissive, we can either define and use a > 'localized' property as follows: > > Local interface types and native types are said to be 'localized' > types. > > Any constructed type that contains a field of a 'localized' type > is also 'localized'. > > Any array or sequence type whose element type is a 'localized' > type is also 'localized'. > > A non-local interface cannot specify any attributes of 'localized' > types, or any operation with a 'localized' result type or parameter > type(s), or that raises any 'localized' exception types. > > Or alternatively, we could force the IDL author to enter a parallel universe > of ecplicitly-local types : > > local struct MyStruct { > native stuff; > }; > > Which is similar to requiring interfaces derived from local interfaces > themselves being marked "local". > > Regards > Nick Date: Fri, 29 Sep 2000 11:37:36 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura Cc: nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: <39D4ADCB.3E3991D@iona.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id e8TFZqC20431 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 3F[!!S2Wd9=&B!!KWNe9 Bob Kukura wrote: > > The following bullet from orbos/99-07-01, section 11.1.1, page 11-380 > pretty clearly indicates that types constructed using local interfaces > are possible, and are themselves locality constrained. > > A local interface is a local type, as is any non-interface type > declaration constructed > using a local interface or other local type. For example, a struct, > union, or > exception with a member that is a local interface is also itself a > local type. > > Maybe we should work native into this set of rules, describining it also > as a "local type". > > -Bob Yes, that is a much better idea. So here goes: Proposed resolution: Local types are already allowed to be included in constructed types. It would be natural to say that the same rules apply to native types. This is done by replacing the paragraph in CORBA 2.4 section 3.10.6 that says (see orbrev/00-09-01): "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type. Any attempt to transmit a value of a native type in a remote invocation may raise the MARSHAL standard system exception"" by the paragraph: "A native type, like a local interface, is a local type, as is any non-interface type declaration constructed using a native or other local type. For example, a struct, union, or exception with a member that is a native is also itself a local type. As such all rules that are enumerated for local types in section 3.7.6 "Local Interfaces" apply to native type. In particular, any attempt to marshal a native type shall result in a MARSHAL standard system exception with standard minor code 2." This just incorporates the properties of local types by reference to the description in the local interfaces section and then highlights those aspects that are of particular importance to native types. Further comments? Thanks, Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Sender: jon@corvette.floorboard.com Message-ID: <39D4C3B7.E9C6BBD2@floorboard.com> Date: Fri, 29 Sep 2000 09:30:47 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: nick.sharman@cp.net, jis@fpk.hp.com, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: <39D4ADCB.3E3991D@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X]7!!UH`!!4#]!!knZ!! Bob Kukura wrote: > > The following bullet from orbos/99-07-01, section 11.1.1, page 11-380 > pretty clearly indicates that types constructed using local interfaces > are possible, and are themselves locality constrained. > > * A local interface is a local type, as is any non-interface type > declaration constructed > using a local interface or other local type. For example, a struct, > union, or > exception with a member that is a local interface is also itself a > local type. > > Maybe we should work native into this set of rules, describining it also > as a "local type". I don't agree. Local interfaces follow all of the language mapping rules for normal interface types as far as embedding in other structured types. Each native types must have explicit rules defined in each language mapping, and the amount of work to define the rules for embedding each native in a struct, union, sequence, array, valuetype, etc is too much, and will only make it harder to keep the language mappings up to date with the core. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 02 Oct 2000 12:47:30 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Bob Kukura , nick.sharman@cp.net, jis@fpk.hp.com, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: <39D4ADCB.3E3991D@iona.com> <39D4C3B7.E9C6BBD2@floorboard.com> Content-Type: multipart/mixed; boundary="------------CE5D44256CBBAACA9738C727" X-UIDL: 7'B!!Y4/!!Xpe!!;52!! Since natives are added only by the OMG, couldn't this be dealt w/ on an ad-hoc basis? Vijay Jonathan Biggar wrote: > Bob Kukura wrote: > > > > The following bullet from orbos/99-07-01, section 11.1.1, page 11-380 > > pretty clearly indicates that types constructed using local interfaces > > are possible, and are themselves locality constrained. > > > > * A local interface is a local type, as is any non-interface type > > declaration constructed > > using a local interface or other local type. For example, a struct, > > union, or > > exception with a member that is a local interface is also itself a > > local type. > > > > Maybe we should work native into this set of rules, describining it also > > as a "local type". > > I don't agree. Local interfaces follow all of the language mapping > rules for normal interface types as far as embedding in other structured > types. Each native types must have explicit rules defined in each > language mapping, and the amount of work to define the rules for > embedding each native in a struct, union, sequence, array, valuetype, > etc is too much, and will only make it harder to keep the language > mappings up to date with the core. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org [] vijayn1.vcf Date: Mon, 02 Oct 2000 16:21:05 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: HF$e9;F\d9Jm1e9YRYd9 Michi Henning wrote: > > On Fri, 29 Sep 2000, Jishnu Mukerji wrote: > > > "A native type, like a local interface, is a local type, as is any > > non-interface type declaration constructed using a native or other > > local type. For example, a struct, union, or exception with a member > > that is a native is also itself a local type. As such all rules that > > are enumerated for local types in section 3.7.6 "Local Interfaces" > > apply to native type. In particular, any attempt to marshal a native > > type shall result in a MARSHAL standard system exception with standard > > minor code 2." > > > > This just incorporates the properties of local types by reference to the > > description in the local interfaces section and then highlights those > > aspects that are of particular importance to native types. > > > > Further comments? > > I like that one! Perhaps the only additional thing to do is add a note that reads: "Note: Specifiers of new native types must specify language mapping for not only how they are passed as parameters but also for how they are included in constructed types (structs, unions, exceptions) and valuetypes." Comments? Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Tue, 3 Oct 2000 06:50:13 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution In-Reply-To: <39D8EE31.2B43888E@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: G1K!!Cm&e9"nXd9MWL!! On Mon, 2 Oct 2000, Jishnu Mukerji wrote: > Perhaps the only additional thing to do is add a note that reads: > > "Note: Specifiers of new native types must specify language mapping > for > not only how they are passed as parameters but also for how they are > included in constructed types (structs, unions, exceptions) and > valuetypes." > > Comments? Sounds entirely resonable. Cheers, Michi. Date: Tue, 3 Oct 2000 06:51:22 +1000 (EST) From: Michi Henning To: Vijaykumar Natarajan cc: Jonathan Biggar , Bob Kukura , nick.sharman@cp.net, jis@fpk.hp.com, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution In-Reply-To: <39D8E652.6000F8E0@inprise.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-ID: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: 5DO!!4@L!!)Dp!!m~6!! On Mon, 2 Oct 2000, Vijaykumar Natarajan wrote: > Since natives are added only by the OMG, couldn't this be dealt w/ on an ad-hoc > basis? I would be quite happy to see addition of new types being made fairly difficult. It's a very good incentive to only add a native type where there is no other option :-) 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 Date: Mon, 02 Oct 2000 15:27:37 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Michi Henning , Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: <39D8EE31.2B43888E@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------DB5EAE2539A24629ADA4DA0E" X-UIDL: o4Ie9o$E!!e~/e9\OVd9 Jishnu Mukerji wrote: > Michi Henning wrote: > > > > On Fri, 29 Sep 2000, Jishnu Mukerji wrote: > > > > > "A native type, like a local interface, is a local type, as is any > > > non-interface type declaration constructed using a native or other > > > local type. For example, a struct, union, or exception with a member > > > that is a native is also itself a local type. As such all rules that > > > are enumerated for local types in section 3.7.6 "Local Interfaces" > > > apply to native type. In particular, any attempt to marshal a native > > > type shall result in a MARSHAL standard system exception with standard > > > minor code 2." > > > > > > This just incorporates the properties of local types by reference to the > > > description in the local interfaces section and then highlights those > > > aspects that are of particular importance to native types. > > > > > > Further comments? > > > > I like that one! > > Perhaps the only additional thing to do is add a note that reads: > > "Note: Specifiers of new native types must specify language mapping for > not only how they are passed as parameters but also for how they are > included in constructed types (structs, unions, exceptions) and > valuetypes." > > Comments? How about: Note: Specifiers of new native types must specify language mapping for not only how they are passed as parameters but also for how they are included in constructed types (structs, unions, exceptions) and valuetypes. Specifiers using preexisting native types in constructed types must specify the language mappings for these types at that time. This covers cases where people reuse existing native types in constructed types Vijay [] vijayn6.vcf Date: Tue, 3 Oct 2000 10:01:42 +1000 (EST) From: Michi Henning To: Vijaykumar Natarajan cc: jis@fpk.hp.com, Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution In-Reply-To: <39D90BD9.EEDE9B51@inprise.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-ID: Content-Type: MULTIPART/MIXED; BOUNDARY=------------DB5EAE2539A24629ADA4DA0E X-UIDL: 15-!!c_W!!$c"!!g5J!! On Mon, 2 Oct 2000, Vijaykumar Natarajan wrote: > > "Note: Specifiers of new native types must specify language mapping for > > not only how they are passed as parameters but also for how they are > > included in constructed types (structs, unions, exceptions) and > > valuetypes." > > > > Comments? > > How about: > Note: Specifiers of new native types must specify language mapping for > not only how they are passed as parameters but also for how they are included in > constructed types (structs, unions, exceptions) and valuetypes. Specifiers using > preexisting native types in constructed types must specify the language mappings > for these types at that time. > > This covers cases where people reuse existing native types in constructed types The term "constructed types" has special meaning, namely, it refers precisely to IDL unions, structs, and enums. Maybe we should just say "complex user-defined types, such as exceptions and valuetypes"? The intent is to convey that this includes everything else, such as, structs, sequences, arrays, unions, etc... Comments? 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 [] vijayn7.vcf Date: Tue, 03 Oct 2000 11:22:59 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan Cc: Michi Henning , Bob Kukura , nick.sharman@cp.net, orb_revision@omg.org Subject: Re: Issue 3258 proposed resolution References: <39D8EE31.2B43888E@fpk.hp.com> <39D90BD9.EEDE9B51@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2i*!!Yb$!!l7Ne9/+~!! Vijaykumar Natarajan wrote: > > Jishnu Mukerji wrote: > > > Michi Henning wrote: > > > > > > On Fri, 29 Sep 2000, Jishnu Mukerji wrote: > > > > > > > "A native type, like a local interface, is a local type, as is any > > > > non-interface type declaration constructed using a native or other > > > > local type. For example, a struct, union, or exception with a member > > > > that is a native is also itself a local type. As such all rules that > > > > are enumerated for local types in section 3.7.6 "Local Interfaces" > > > > apply to native type. In particular, any attempt to marshal a native > > > > type shall result in a MARSHAL standard system exception with standard > > > > minor code 2." > > > > > > > > This just incorporates the properties of local types by reference to the > > > > description in the local interfaces section and then highlights those > > > > aspects that are of particular importance to native types. > > > > > > > > Further comments? > > > > > > I like that one! > > > > Perhaps the only additional thing to do is add a note that reads: > > > > "Note: Specifiers of new native types must specify language mapping for > > not only how they are passed as parameters but also for how they are > > included in constructed types (structs, unions, exceptions) and > > valuetypes." > > > > Comments? > > How about: > Note: Specifiers of new native types must specify language mapping for > not only how they are passed as parameters but also for how they are included in > constructed types (structs, unions, exceptions) and valuetypes. Specifiers using > preexisting native types in constructed types must specify the language mappings > for these types at that time. > > This covers cases where people reuse existing native types in constructed types > > Vijay I don't believe the transitory case needs to be covered in the standards document. All that needs to be done is to raise issues with the language mapping RTFs to fix the outage. So I am opposed to adding the last sentence proposed above. It does not belong in a standards document. We can add the filing of issues to the action taken section of the resolution, and make sure that the issue are filed for each existing native types for each language mapping RTF. That might actually cause those outages to be fixed even.:-) Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Tue, 03 Oct 2000 11:29:08 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Subject: Re: Issue 3258 proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: <]Ud98d3!!iX)!!R0d!! Michi Henning wrote: > > On Mon, 2 Oct 2000, Vijaykumar Natarajan wrote: > > > > "Note: Specifiers of new native types must specify language mapping for > > > not only how they are passed as parameters but also for how they are > > > included in constructed types (structs, unions, exceptions) and > > > valuetypes." > > > > > > Comments? > > > > How about: > > Note: Specifiers of new native types must specify language mapping for > > not only how they are passed as parameters but also for how they are included in > > constructed types (structs, unions, exceptions) and valuetypes. Specifiers using > > preexisting native types in constructed types must specify the language mappings > > for these types at that time. > > > > This covers cases where people reuse existing native types in constructed types > > The term "constructed types" has special meaning, namely, it refers precisely > to IDL unions, structs, and enums. Maybe we should just say "complex > user-defined types, such as exceptions and valuetypes"? > > The intent is to convey that this includes everything else, such as, > structs, sequences, arrays, unions, etc... > > Comments? So how about: "Note: Specifiers of new native types must specify language mapping for not only how they are passed as parameters but also for how they are included in constructed types and other complex user defined types such as exceptions and valuetypes." Additionally the action taken field will read: 1. File issues against all language mapping RTFs to do what is stated in the Note: for all existing standard native types. 2. Incorporate changes and close issue. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Tue, 03 Oct 2000 16:43:37 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: [Fwd: Issue 3258 proposed resolution] Content-Type: multipart/mixed; boundary="------------866417BFB1D6A43951102F83" X-UIDL: @dH!!B66!!ook!!$d!!! This one did not make it to the orb_revision list. So herre goes. See attached. Jishnu.Received: from fpk.hp.com (fpk-jmukerji.fpk.hp.com [15.73.22.32]) by sleepy.fpk.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.7.3 SMKit7.01) id LAA24481; Tue, 3 Oct 2000 11:29:11 -0400 (EDT) Message-ID: <39D9FB44.F00B7F18@fpk.hp.com> Date: Tue, 03 Oct 2000 11:29:08 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Subject: Re: Issue 3258 proposed resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michi Henning wrote: > > On Mon, 2 Oct 2000, Vijaykumar Natarajan wrote: > > > > "Note: Specifiers of new native types must specify language mapping for > > > not only how they are passed as parameters but also for how they are > > > included in constructed types (structs, unions, exceptions) and > > > valuetypes." > > > > > > Comments? > > > > How about: > > Note: Specifiers of new native types must specify language mapping for > > not only how they are passed as parameters but also for how they are included in > > constructed types (structs, unions, exceptions) and valuetypes. Specifiers using > > preexisting native types in constructed types must specify the language mappings > > for these types at that time. > > > > This covers cases where people reuse existing native types in constructed types > > The term "constructed types" has special meaning, namely, it refers precisely > to IDL unions, structs, and enums. Maybe we should just say "complex > user-defined types, such as exceptions and valuetypes"? > > The intent is to convey that this includes everything else, such as, > structs, sequences, arrays, unions, etc... > > Comments? So how about: "Note: Specifiers of new native types must specify language mapping for not only how they are passed as parameters but also for how they are included in constructed types and other complex user defined types such as exceptions and valuetypes." Additionally the action taken field will read: 1. File issues against all language mapping RTFs to do what is stated in the Note: for all existing standard native types. 2. Incorporate changes and close issue. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Oct 2000 15:31:20 -0400 To: orb_revision@omg.org From: Victor Giddings Subject: Re: [Fwd: Issue 3258 proposed resolution] In-Reply-To: <39DA44F9.9EA5629C@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: p$d!!n;8e91a)e9VSe!! At 04:43 PM 10/3/00 -0400, Jishnu Mukerji wrote: >This one did not make it to the orb_revision list. So herre goes. See >attached. [...] >So how about: > >"Note: Specifiers of new native types must specify language mapping for >not only how they are passed as parameters but also for how they are >included in >constructed types and other complex user defined types such as >exceptions and >valuetypes." > >Additionally the action taken field will read: > >1. File issues against all language mapping RTFs to do what is stated in >the Note: for all existing standard native types. > >2. Incorporate changes and close issue. > >Jishnu. I may have lost the thread on this issue. Is it still the intent that these "constructed types and other complex user defined types such as exceptions and valuetypes" be "local"? This seems to have been lost in this text. Victor Giddings victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 296 6501 X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Oct 2000 15:31:20 -0400 To: orb_revision@omg.org From: Victor Giddings Subject: Re: [Fwd: Issue 3258 proposed resolution] In-Reply-To: <39DA44F9.9EA5629C@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: p$d!!n;8e91a)e9VSe!! At 04:43 PM 10/3/00 -0400, Jishnu Mukerji wrote: >This one did not make it to the orb_revision list. So herre goes. See >attached. [...] >So how about: > >"Note: Specifiers of new native types must specify language mapping for >not only how they are passed as parameters but also for how they are >included in >constructed types and other complex user defined types such as >exceptions and >valuetypes." > >Additionally the action taken field will read: > >1. File issues against all language mapping RTFs to do what is stated in >the Note: for all existing standard native types. > >2. Incorporate changes and close issue. > >Jishnu. I may have lost the thread on this issue. Is it still the intent that these "constructed types and other complex user defined types such as exceptions and valuetypes" be "local"? This seems to have been lost in this text. Victor Giddings victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 296 6501 Date: Mon, 09 Oct 2000 16:57:56 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Victor Giddings Cc: orb_revision@omg.org Subject: Re: [Fwd: Issue 3258 proposed resolution] References: <4.3.2.7.2.20001004152045.01ef2760@postel> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: F3Ie9(>/!!'g8!!))nd9 Victor Giddings wrote: > > At 04:43 PM 10/3/00 -0400, Jishnu Mukerji wrote: > >This one did not make it to the orb_revision list. So herre goes. See > >attached. > [...] > >So how about: > > > >"Note: Specifiers of new native types must specify language mapping for > >not only how they are passed as parameters but also for how they are > >included in > >constructed types and other complex user defined types such as > >exceptions and > >valuetypes." > > > >Additionally the action taken field will read: > > > >1. File issues against all language mapping RTFs to do what is stated in > >the Note: for all existing standard native types. > > > >2. Incorporate changes and close issue. > > > >Jishnu. > > I may have lost the thread on this issue. Is it still the intent that > these "constructed types and other complex user defined types such as > exceptions and valuetypes" be "local"? This seems to have been lost > in this text. I thought that they have always been local. How do you do a non-local struct, union exception or enum anyway? And valuetypes are explicitly defined to be local I thought. What am I missing? Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Wed, 18 Oct 2000 14:25:37 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 3258 Final draft resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0>p!!9$Nd9n!e!!:a:e9 Here is the final draft that will be placed on the next vote: Issue 3258: Can native be used in constructed IDL types? (orb_revision) Click here for this issue's archive. Source: Floorboard Software (Jonathan Biggar jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: CORBA 2.3.1, section 3.10.5 says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." This is ambiguous as to whether a native type may be used in a constructed IDL type that is intended to be used only locally: // IDL native MyNative; struct MyStruct { MyNative a_native; }; So, should the first sentence in 3.10.5 be read to mean that native may ONLY be used in parameters & results? If so, we ought to put the word "only" in there. Resolution: Local types are already allowed to be included in constructed types. It would be natural to say that the same rules apply to native types. This would also remove the ambiguity in the current text. Furthermore, it should be made incumbant upon those specifying new native types to provide details of language mapping that are necessary for using the new native type in all possible circumstances. New issues should be raised with language mapping RTFs to complete the specification of existing native types where they are found to be incomplete. Revised Text: 1. Replace the paragraph in CORBA 2.4 section 3.10.6 that says (see orbrev/00-09-01): "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type. Any attempt to transmit a value of a native type in a remote invocation may raise the MARSHAL standard system exception"" by the paragraph: "A native type, like a local interface, is a local type, as is any non-interface type declaration constructed using a native or other local type. For example, a struct, union, or exception with a member that is a native is also itself a local type. As such all rules that are enumerated for local types in section 3.7.6 "Local Interfaces" apply to native type. In particular, any attempt to marshal a native type shall result in a MARSHAL standard system exception with standard minor code 2." This just incorporates the properties of local types by reference to the description in the local interfaces section and then highlights those aspects that are of particular importance to native types. 2. Insert the following note immediately following the replaced paragraph above: "Note: Specifiers of new native types must specify language mapping for not only how they are passed as parameters but also for how they are included in complex user defined types such as structs, unions, arrays, sequences, exceptions and valuetypes." Actions to be taken: 1. File issues against all language mapping RTFs to do what is stated in the Note: for all existing standard native types. 2. Incorporate changes and close issue. February 7, 2000: received issue _______________________________________________________________ Comments? Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Sender: jbiggar@corvette.floorboard.com Message-ID: <39F618B7.8D9DCDC2@floorboard.com> Date: Tue, 24 Oct 2000 16:18:15 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org Subject: Re: Core RTF NM Vote 9 Announcement References: <39F0A9E5.13664ABA@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b%a!!k,0!!=`Z!!m/U!! Issue 3258: Can native be used in constructed IDL types? I'm going to take this opportunity before most people have submitted their votes to go on the stump again opposing the proposed resolution to 3258. I think it is a needless complication to allow native types to be embedded in IDL structured data types, and it has not been necessary to do so at this point. The CORBA core only defines 6 native types: AbstractBase, ValueFactory, Servant, Cookie, PriorityMapping, and PriorityTransform. None of these types are ever used as anything but an operation argument or return value. The state of the art does not require this change, and I haven't seen anyone argue that they need this capability. Opening up IDL structured data types to allow native members without a pressing need just complicates IDL compilers for no obvious gain. I prefer my original resolution, which is to outlaw the use of native types except as operation arguments and return values. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Jeffrey Mischkinsky Message-Id: <200010250024.RAA11078@wheel.dcn.davis.ca.us> Subject: Re: Core RTF NM Vote 9 Announcement To: jon@floorboard.com (Jonathan Biggar) Date: Tue, 24 Oct 2000 17:24:50 -0700 (PDT) Cc: jis@fpk.hp.com, orb_revision@omg.org In-Reply-To: <39F618B7.8D9DCDC2@floorboard.com> from "Jonathan Biggar" at Oct 24, 2000 04:18:15 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,7E!!g<1!!\V\!!/^J!! 'Jonathan Biggar' writes: > > Issue 3258: Can native be used in constructed IDL types? > > I'm going to take this opportunity before most people have submitted > their votes to go on the stump again opposing the proposed resolution to > 3258. > > I think it is a needless complication to allow native types to be > embedded in IDL structured data types, and it has not been necessary to > do so at this point. > > The CORBA core only defines 6 native types: AbstractBase, ValueFactory, > Servant, Cookie, PriorityMapping, and PriorityTransform. None of these > types are ever used as anything but an operation argument or return > value. The state of the art does not require this change, and I haven't > seen anyone argue that they need this capability. > > Opening up IDL structured data types to allow native members without a > pressing need just complicates IDL compilers for no obvious gain. > > I prefer my original resolution, which is to outlaw the use of native > types except as operation arguments and return values. I tend to agree with Jon. Native types are yet another attempt to introduce PIDL like things into IDL. Particularly with the introduction of local interface we should be striving to limit their use as much as possible. In order to define a native, one must explicitly specify its language mapping in ALL languages. It requires special caseing in generated code, etc., etc. In effect, the use of a native type as a parameter type "contaminates" any operation in which it is used. The less, the better. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 To: Jonathan Biggar cc: jis@fpk.hp.com, orb_revision@omg.org Subject: Re: Core RTF NM Vote 9 Announcement In-Reply-To: Your message of "Tue, 24 Oct 2000 16:18:15 PDT." <39F618B7.8D9DCDC2@floorboard.com> From: Bill Janssen Message-Id: <00Oct24.185819pdt."3441"@watson.parc.xerox.com> Date: Tue, 24 Oct 2000 18:58:13 PDT Content-Type: text X-UIDL: Q!@e9Qm7!!OV(!!$N&!! > Opening up IDL structured data types to allow native members without a > pressing need just complicates IDL compilers for no obvious gain. > > I prefer my original resolution, which is to outlaw the use of native > types except as operation arguments and return values. You're absolutely correct, Jon. Bill Date: Fri, 27 Oct 2000 15:05:59 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 3258 - one more time Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \-&!!>,Od9>@/!!=4 Date: Fri, 27 Oct 2000 12:57:31 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: orb_revision@omg.org Subject: Re: Issue 3258 - one more time References: <39F9D216.6D85EA2F@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: EQTd9??^d9(5#!!YkU!! Jishnu Mukerji wrote: > > Since we knaow that the more elaborate resolution to this issue won't > fly any further than a lead balloon now..... here is the other > resolution that I had proposed originally: > > Issue 3258: Can native be used in constructed IDL types? (orb_revision) [snipped for brevity] > Proposed resolution: > > While the second sentence in the quoted text from 2.3.1 section > 3.10.5 > alludes to using natives in constructed types, trying to generalize > its > use in general structs etc adds considerable complexity to > marshaling > time checking etc. So native should not be allowed anywhere else > other > than as parameter or return value type sepecification unless of > course a > very pressing use case is found for allowing it. Since we have not > seen > such a use case yet, it is prposed that native be restricted to > specifying parameter types only. This is done by changing the two > sentences in CORBA 2.3.1 section 3.10.5 that says: > > "A native type may be used to define operation parameters and > results. > However, there is no requirement that values of the type be > permitted in > remote invocations, either directly or as a component of a > constructed > type." > > to read: > > "A native type may only be used to define operation parameters and > results. Native type parameters are not permitted in operations in > interfaces that are not local." > > ___________________________________________________________________ > > Unless I hear significant additional discussion of on this matter, > this > will appear in the next vote. > > Comments? Ok, I'll stir the pot a little more. :) What about valuetype operations? I can't think of a reason not to allow it, since valuetype operation invocations are always local. I think it would be better to rewrite the resolution in a prescriptive manner rather than proscriptive, in order to avoid this question in the future: "A native type may only be used to define operation parameters and results. Native type parameters are only permitted in operations of local interfaces or valuetypes." -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 27 Oct 2000 16:20:42 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: orb_revision@omg.org Subject: Re: Issue 3258 - one more time References: <39F9D216.6D85EA2F@fpk.hp.com> <39F9DE2B.1FAC2AD9@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: cZ)!!cZ&!!Okid9'Q-!! Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > Since we knaow that the more elaborate resolution to this issue won't > > fly any further than a lead balloon now..... here is the other > > resolution that I had proposed originally: > > > > Issue 3258: Can native be used in constructed IDL types? (orb_revision) > > [snipped for brevity] > > > Proposed resolution: > > > > While the second sentence in the quoted text from 2.3.1 section 3.10.5 > > alludes to using natives in constructed types, trying to generalize its > > use in general structs etc adds considerable complexity to marshaling > > time checking etc. So native should not be allowed anywhere else other > > than as parameter or return value type sepecification unless of course a > > very pressing use case is found for allowing it. Since we have not seen > > such a use case yet, it is prposed that native be restricted to > > specifying parameter types only. This is done by changing the two > > sentences in CORBA 2.3.1 section 3.10.5 that says: > > > > "A native type may be used to define operation parameters and results. > > However, there is no requirement that values of the type be permitted in > > remote invocations, either directly or as a component of a constructed > > type." > > > > to read: > > > > "A native type may only be used to define operation parameters and > > results. Native type parameters are not permitted in operations in > > interfaces that are not local." > > > > ___________________________________________________________________ > > > > Unless I hear significant additional discussion of on this matter, this > > will appear in the next vote. > > > > Comments? > > Ok, I'll stir the pot a little more. :) > > What about valuetype operations? I can't think of a reason not to allow > it, since valuetype operation invocations are always local. I think it > would be better to rewrite the resolution in a prescriptive manner > rather than proscriptive, in order to avoid this question in the future: > > "A native type may only be used to define operation parameters and > results. Native type parameters are only permitted in operations of > local interfaces or valuetypes." Of course you are right. If you had said so in the first place.......:-) I'll change the proposal to reflect this. Thanks, Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com