Issue 665: TypeCode equality (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: TypeCode equality is not very well-specified or portable. Resolution: Incorporate more complete specification as shown below: Revised Text: In section 3.8.2 following to the paragraph describing the any type: Actions taken: August 11, 1997: received issue May 12, 1998: issue moved from port-rtf to orb_revision February 23, 1999: closed issue Discussion: : complete the changes that were intended in the resolution of issue 665 by adding the missing pieces in Chapter 15 Revised Text: Page 15-23, first para following heading "Encoded Idnetifiers and Names": Change the para to read: The Repository ID parameters in tk_objref, tk_struct, tk_union, tk_enum, tk_alias, tk_except, tk_native, tk_value, tk_value_box and tk_abstract_interface TypeCodes are Interface Repository RepositoryId values, whose format is described in the specification of the Interface Repository. For GIOP 1.2 onwards, repositoryID values are mandatory. For GIOP 1.0 and 1.1, RepositoryId values are required for tk_objref and tk_except TypeCodes; for tk_struct, tk_union, tk_enum, and tk_alias TypeCodes RepositoryIds are optional and encoded as empty strings if omitted. Actions taken: Send this issue with the recommendation to adopt the proposed resolution and revised text as above to the Interop RTF, with a strong End of Annotations:===== Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Mon, 11 Aug 1997 18:49:20 -0400 To: issues@omg.org, port-rtf@omg.org From: Steve Vinoski Subject: TypeCode equality TypeCode equality is not very well-specified or portable. Here's two quotes from the CORBA spec: 1) The CORBA spec says "Equal TypeCodes are interchangeable, and give identical results when TypeCode operations are applied to them." (OMG document formal/97-02-25, page 6-36). 2) It also says the following about the marshaling of TypeCodes (OMG document orbos/96-05-01, page 12-12): (begin quoted text) "The Repository ID parameters in tk_objref, tk_struct, tk_union, tk_enum, tk_alias, and tk_except TypeCodes are Interface Repository RepositoryId values, whose format is described in the specification of of the Interface Repository. RepositoryId values are required for tk_objref and tk_except TypeCodes; for other TypeCodes they are optional and are encoded as empty strings if omitted. The name parameters in tk_objref, tk_struct, tk_union, tk_enum, tk_alias, and tk_except TypeCodes and the member name parameters in tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified by (or significant in) GIOP. Agents should not make assumptions about type equivalence based on these name values; only the structural information (including RepositoryId values, if provided) is significant. If provided, the strings should be the simple, unscoped names supplied in the OMG IDL definition text. If omitted, they are encoded as empty strings." (end quoted text) First of all, note that the two quotes given here are contradictory. Let's focus on tk_struct TypeCodes as an example. As described in the quotes from the spec, the RepositoryId and member names for struct types are optional in GIOP. This means that a conforming ORB can transmit either of the following for a "struct X" TypeCode: TC ID Repos ID Type Name Member Count Member Name Member TC ID ======================================================================== 15 "IDL:X:1.0" "X" 1 "l" 3 15 "" "" 1 "" 3 By the definition of TypeCode::equal() given in the first quote above, these TypeCodes are not equal, though they are both conforming as far as the GIOP transfer syntax goes. However, we know they are equal, because they're for the same type. Interesting. Assume I have two ORBs: one that always includes string members and RepositoryIds when it marshals TypeCodes (ORB A) and one that doesn't (ORB B). What if ORB A sends a TypeCode for struct X to ORB B, which then sends it back to ORB A? The TypeCode leaves ORB A containing all the info provided in the first TypeCode representation, and arrives back containing only the info shown in the second representation. Should the two TypeCodes compare equal? Codewise, it looks like this: // IDL interface TC_Experiment { CORBA::TypeCode passback(in CORBA::TypeCode tc); }; // C++ client TC_Experiment_var tce = // get objref from somewhere... CORBA::TypeCode_var tc = tce->passback(_tc_X); CORBA::Boolean result = tc->equal(_tc_X); // C++ server CORBA::TypeCode_ptr MyTCExperiment::passback(CORBA::TypeCode_ptr tc) { return CORBA::TypeCode::_duplicate(tc); } The TC_Experiment::passback() operation is implemented in the server to just return a duplicate of its argument. The client uses a TypeCode constant generated by the IDL compiler as the input argument, and then calls TypeCode::equal() on the returned TypeCode passing in the original. According to the first quote above, the result of equal() should be false. According to the second quote, the result should be true. Obviously, the result should be true. This all boils down to structural vs. name equivalence. Both have their place, so mandating one or the other is not the answer. Proposed fix: 1) Since TypeCode::equal is already well-specified by formal/97-02-25, page 6-36, we should leave it alone. 2) To enable checking for structural equivalence, a new operation should be added to TypeCode: boolean TypeCode::equivalent(in CORBA::TypeCode tc); This operation ignores all optional TypeCode parts, basing its result only on the required parts. For tk_alias TypeCodes, the result of equivalent() is based only on their content TypeCodes (i.e., aliases are "unaliased" before comparison). 3) If an ORB receives a TypeCode containing optional parts, it should be required to preserve those parts, especially if it sends that TypeCode elsewhere as part of another request. This will eliminate the surprising results that are possible with the current specs as shown by the TC_Experiment example given above. 4) The TypeCode comparison performed by the C++ Mapping Any extraction operator>>=() should be based on TypeCode::equivalent(), not TypeCode::equal(). This is because in practice I believe this is what most people do and is what most users would expect. --steve Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 12 Aug 1997 10:17:05 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: issues@omg.org, port-rtf@omg.org Subject: Re: TypeCode equality On Mon, 11 Aug 1997, Steve Vinoski wrote: > This all boils down to structural vs. name equivalence. Both have their > place, so mandating one or the other is not the answer. > > Proposed fix: > > 1) Since TypeCode::equal is already well-specified by formal/97-02-25, > page 6-36, we should leave it alone. > > 2) To enable checking for structural equivalence, a new operation > should be added to TypeCode: > > boolean TypeCode::equivalent(in CORBA::TypeCode tc); > > This operation ignores all optional TypeCode parts, basing its result > only on the required parts. For tk_alias TypeCodes, the result of > equivalent() is based only on their content TypeCodes (i.e., aliases > are "unaliased" before comparison). Steve, as you describe it, TypeCode::equivalent() will return TRUE for the following two IDL structure types: struct X { long a; short b; }; struct Y { long member; short member2; }; This may be exactly what is required, but I suspect it will be too loose in some cases. What I would really like (for example to determine type compatibility for exporting service offers to a trader) is name equivalence ignoring aliases. For example, if with the above IDL, we also have typedef X Z; then this "de-aliased equivalence" would return TRUE for de_aliased_equivalent(X, Z) but would return FALSE for de_aliased_equivalent(X, Y) and de_aliased_equivalent(Z, Y) The reason I am suggesting this is that exact type equivalence (as for TypeCode::equal()) is too strict for a trader. However, many people would argue that TypeCode::equivalent() as you describe it above is too loose (just because two bits of information have the same structure, that doesn't mean that it makes sense semantically to treat one as the other). The problem with de_aliased_equivalent() seems to be that to implement it, all ORBs would be obliged to always marshall the type name and member name in the type code. I am not sure whether imposing this restriction after the fact is feasible. Can anyone comment on current practice in various ORBs? Are the additional names currently thrown away by existing implementations? I really would like to have this de-aliased equivalence as a third option. In practice, it will be used quite a lot, and if the platform does not provide it, developers will forever be trying to emulate it. If something like de_aliased_equivalent() cannot be added, I guess we have to live with equal() and the equivalent() operation suggested by Steve. > 3) If an ORB receives a TypeCode containing optional parts, it should > be required to preserve those parts, especially if it sends that > TypeCode elsewhere as part of another request. This will eliminate the > surprising results that are possible with the current specs as shown > by the TC_Experiment example given above. That seems mandatory, otherwise the strange effects you describe will happen. This raises the question though - if an ORB always must preserve the details of a *received* type code, couldn't you just as well oblige the ORB to always *provide* the details? It seems that given the first obligation, the second one would add little extra overhead, and it would enable de-aliased name equivalence comparisons. > 4) The TypeCode comparison performed by the C++ Mapping Any extraction > operator>>=() should be based on TypeCode::equivalent(), not > TypeCode::equal(). This is because in practice I believe this is what > most people do and is what most users would expect. Yes, I agree. There is an additional issue here though. Should extraction from an Any into a "wider" type be allowed? Currently, the following extraction will fail: CORBA::Any a; a <<= (CORBA::Short)5; CORBA::Long l; a >>= l; // Extraction fails, type mismatch You could conceivably define extraction to follow the normal C++ type promotion rules, so a short can be promoted to a long, and a float to a double. This would make type Any a bit easier to use. I am not sure whether the convenience is worth it though. For example, with type promotion, successful extraction from an Any followed by injection back into the Any would not guarantee to preserve the type code. Opinions anyone? 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 Return-Path: Sender: jon@sems.com Date: Mon, 11 Aug 1997 18:03:59 -0700 From: Jonathan Biggar Organization: Seagate Software, Network & Storage Management Group To: Michi Henning Cc: Steve Vinoski , issues@omg.org, port-rtf@omg.org Subject: Re: TypeCode equality References: Perhaps we could define it like this: enum EquivalenceRule { TC_STRICT, TC_IGNORE_ALIASES, TC_STRUCTURAL_ONLY }; boolean TypeCode::equivalent(in CORBA::TypeCode tc, EquivalenceRule rule); Where STRICT is just like equal(), IGNORE_ALIASES gets what Michi wants, and STRUCTURAL_ONLY gets what Steve wants. (I don't see a need for a structural comparison that does not ignore aliases.) Then TypeCode::equal() could be deprecated in favor of the new interface. Jon Michi Henning wrote: > On Mon, 11 Aug 1997, Steve Vinoski wrote: > > > This all boils down to structural vs. name equivalence. Both have their > > place, so mandating one or the other is not the answer. > > > > Proposed fix: > > > > 1) Since TypeCode::equal is already well-specified by formal/97-02-25, > > page 6-36, we should leave it alone. > > > > 2) To enable checking for structural equivalence, a new operation > > should be added to TypeCode: > > > > boolean TypeCode::equivalent(in CORBA::TypeCode tc); > > > > This operation ignores all optional TypeCode parts, basing its result > > only on the required parts. For tk_alias TypeCodes, the result of > > equivalent() is based only on their content TypeCodes (i.e., aliases > > are "unaliased" before comparison). > > Steve, > > as you describe it, TypeCode::equivalent() will return TRUE for the > following two IDL structure types: > > struct X { > long a; > short b; > }; > > struct Y { > long member; > short member2; > }; > > This may be exactly what is required, but I suspect it will be too loose > in some cases. What I would really like (for example to determine type > compatibility for exporting service offers to a trader) is name equivalence > ignoring aliases. > > For example, if with the above IDL, we also have > > typedef X Z; > > then this "de-aliased equivalence" would return TRUE for > > de_aliased_equivalent(X, Z) > > but would return FALSE for > > de_aliased_equivalent(X, Y) and de_aliased_equivalent(Z, Y) > > The reason I am suggesting this is that exact type equivalence (as for > TypeCode::equal()) is too strict for a trader. However, many people would > argue that TypeCode::equivalent() as you describe it above is too loose > (just because two bits of information have the same structure, that > doesn't mean that it makes sense semantically to treat one as the other). > > The problem with de_aliased_equivalent() seems to be that to implement > it, all ORBs would be obliged to always marshall the type name and member > name in the type code. I am not sure whether imposing this restriction > after the fact is feasible. Can anyone comment on current practice in > various ORBs? Are the additional names currently thrown away by existing > implementations? > > I really would like to have this de-aliased equivalence as a third option. > In practice, it will be used quite a lot, and if the platform does not > provide it, developers will forever be trying to emulate it. > > If something like de_aliased_equivalent() cannot be added, I guess > we have to live with equal() and the equivalent() operation suggested > by Steve. > > > 3) If an ORB receives a TypeCode containing optional parts, it should > > be required to preserve those parts, especially if it sends that > > TypeCode elsewhere as part of another request. This will eliminate the > > surprising results that are possible with the current specs as shown > > by the TC_Experiment example given above. > > That seems mandatory, otherwise the strange effects you describe will > happen. This raises the question though - if an ORB always must preserve > the details of a *received* type code, couldn't you just as well oblige > the ORB to always *provide* the details? It seems that given the first > obligation, the second one would add little extra overhead, and it would > enable de-aliased name equivalence comparisons. > > > 4) The TypeCode comparison performed by the C++ Mapping Any extraction > > operator>>=() should be based on TypeCode::equivalent(), not > > TypeCode::equal(). This is because in practice I believe this is what > > most people do and is what most users would expect. > > Yes, I agree. > > There is an additional issue here though. Should extraction from an Any > into a "wider" type be allowed? > > Currently, the following extraction will fail: > > CORBA::Any a; > a <<= (CORBA::Short)5; > > CORBA::Long l; > a >>= l; // Extraction fails, type mismatch > > You could conceivably define extraction to follow the normal C++ type > promotion rules, so a short can be promoted to a long, and a float > to a double. > > This would make type Any a bit easier to use. I am not sure whether > the convenience is worth it though. For example, with type promotion, > successful extraction from an Any followed by injection back into the > Any would not guarantee to preserve the type code. Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 12 Aug 1997 11:11:12 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Steve Vinoski , port-rtf@omg.org Subject: Re: TypeCode equality On Mon, 11 Aug 1997, Jonathan Biggar wrote: > Perhaps we could define it like this: > > enum EquivalenceRule { TC_STRICT, TC_IGNORE_ALIASES, > TC_STRUCTURAL_ONLY }; > boolean TypeCode::equivalent(in CORBA::TypeCode tc, EquivalenceRule > rule); > > Where STRICT is just like equal(), IGNORE_ALIASES gets what Michi > wants, and > STRUCTURAL_ONLY gets what Steve wants. (I don't see a need for a > structural > comparison > that does not ignore aliases.) > > Then TypeCode::equal() could be deprecated in favor of the new > interface. Sounds very nice to me. The only caveat is that ignoring aliases places some additional obligations on the ORB about preserving names in type codes, I'm not sure whether that's feasible. Steve, you have lots of implementation experience there - do you think this could be done without rocking the boat too much? 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 Return-Path: Date: Mon, 11 Aug 1997 19:18:59 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning , Jonathan Biggar Subject: Re: TypeCode equality CC: Steve Vinoski , issues@omg.org, port-rtf@omg.org References: <33EFB67E.5EAB7C39@sems.com> Excerpts from local.omg: 11-Aug-97 Re: TypeCode equality Jonathan Biggar@sems.com (5021*) > Perhaps we could define it like this: > enum EquivalenceRule { TC_STRICT, TC_IGNORE_ALIASES, TC_STRUCTURAL_ONLY }; > boolean TypeCode::equivalent(in CORBA::TypeCode tc, EquivalenceRule rule); > Where STRICT is just like equal(), IGNORE_ALIASES gets what Michi wants, and > STRUCTURAL_ONLY gets what Steve wants. (I don't see a need for a structural > comparison > that does not ignore aliases.) Aieeee! Implement three different interfaces instead of one!? Bill Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 12 Aug 1997 12:31:19 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: Bill Janssen cc: Jonathan Biggar , Steve Vinoski , issues@omg.org, port-rtf@omg.org Subject: Re: TypeCode equality On Mon, 11 Aug 1997, Bill Janssen wrote: > > Aieeee! Implement three different interfaces instead of one!? > Why, don't you like swiss-army knives? ;-) Actually, this really is a language mapping issue anyway. In PIDL, you can use an enum or three different operations, it doesn't matter - the language binding ultimately maps this to whatever is most convenient. I agree with your sentiment though. The choice of comparison semantics is probably fundamental enough to justify using three different operations, instead of a parameter. I expect that in practice, the desired flavour of comparison will always be fixed at compile time. 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 Return-Path: Sender: jon@sems.com Date: Tue, 12 Aug 1997 09:56:16 -0700 From: Jonathan Biggar Organization: Seagate Software, Network & Storage Management Group To: Bill Janssen Cc: Michi Henning , Jonathan Biggar , Steve Vinoski , issues@omg.org, port-rtf@omg.org Subject: Re: TypeCode equality References: <33EFB67E.5EAB7C39@sems.com> Bill Janssen wrote: > Excerpts from local.omg: 11-Aug-97 Re: TypeCode equality Jonathan > Biggar@sems.com (5021*) > > > Perhaps we could define it like this: > > > enum EquivalenceRule { TC_STRICT, TC_IGNORE_ALIASES, > TC_STRUCTURAL_ONLY }; > > boolean TypeCode::equivalent(in CORBA::TypeCode tc, > EquivalenceRule rule); > > > Where STRICT is just like equal(), IGNORE_ALIASES gets what Michi > wants, and > > STRUCTURAL_ONLY gets what Steve wants. (I don't see a need for a > structural > > comparison > > that does not ignore aliases.) > > Aieeee! Implement three different interfaces instead of one!? Maybe I'm just an implementer at heart, but I don't understand the fuss. Wouldn't you likely implement it this way internally anyway, just to share the common parts of the algorithm? Jon Return-Path: Sender: jon@floorboard.com Date: Mon, 11 May 1998 12:29:46 -0700 From: Jonathan Biggar To: orb_revision@omg.org, ter@holta.ho.lucent.com Subject: Update on TypeCode equality proposal Here is the latest version of the TypeCode equality proposal, with a few questions that I'd like some comments on. Please let me (and Tom Rutt) know what your opinion is on this as soon as possible. Proposal: 1. Make RepositoryIds mandatory for struct, union, enum, and alias typecodes. 2. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics: a) If the two TypeCodes are the same primitive type (null, void, short, long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode, longlong, ulonglong, longdouble, wchar) then equivalent() returns true. b) If the two TypeCodes are string, wstring or fixed with the same parameters (bounds, digits or scale) then equivalent() returns true. c) If the two TypeCodes are both arrays or both sequences, with the same bounds and component type, then equivalent() returns true. [See Question 1, below.] d) If the two TypeCodes are both structs, unions, enums or aliases, and they have the same RepositoryId, then equivalent() returns true. [See Questions 2 and 3, below.] e) If one of the two TypeCodes is a direct or indirect alias of the other one, then equivalent() returns true(). This means that for the following IDL: typedef Long A; typedef Long B; typedef A C; Long & A are equivalent, Long & B are equivalent, A & C are equivalent, but A & B are not. This seems to be the best compromise between semi-strong typed languages like C and C++ where typedefs do not define new types, and strong typed languages like Ada, where typedefs do define new types. This solution seems to provide the best level of interoperability. f) Otherwise, equivalent() returns false. Question 1: What does it mean for the component type of arrays or sequences to be the same? Do we recursively apply equivalent, or is it stricter. For example: typedef long Foo; typedef long LongArray[10]; typedef Foo FooArray[10]; are LongArray and FooArray equivalent or not? Question 2: If two TypeCodes with RepositoryIds have the same RepositoryId, do we require equivalent to also check their components as well? Doing this is slower, but more robust in face of IDL version skew. Question 3: What should the comparison semantics be if one TypeCode has a RepositoryId and the other one doesn't, in order to allow the best interoperability between ORBs supporting the new spec and older ones? Should we declare the types to be different, or just fall back on a structural comparison? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 12 May 1998 06:38:47 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org, ter@holta.ho.lucent.com Subject: Re: Update on TypeCode equality proposal On Mon, 11 May 1998, Jonathan Biggar wrote: > Here is the latest version of the TypeCode equality proposal, with a few > questions that I'd like some comments on. Please let me (and Tom Rutt) > know what your opinion is on this as soon as possible. Sounds good to me. > e) If one of the two TypeCodes is a direct or indirect alias of the > other one, then equivalent() returns true(). This means that for > the > following IDL: > > typedef Long A; > typedef Long B; > typedef A C; > > Long & A are equivalent, Long & B are equivalent, A & C are > equivalent, > but A & B are not. This seems to be the best compromise between > semi-strong typed languages like C and C++ where typedefs do not > define > new types, and strong typed languages like Ada, where typedefs do > define > new types. This solution seems to provide the best level of > interoperability. Question: I take it that the same logic would apply to multi-hop aliases? typedef long A; typedef long B; typedef A C; In this case, long, A, and C would compare equivalent, and B and C would not? > Question 1: What does it mean for the component type of arrays or > sequences to be the same? Do we recursively apply equivalent, or is > it > stricter. For example: > > typedef long Foo; > typedef long LongArray[10]; > typedef Foo FooArray[10]; > > are LongArray and FooArray equivalent or not? My feeling is that they should not be equivalent. Consider: const long b1 = 10; const long b2 = 20; typedef long LongArray[b1]; typedef long Foo; typedef Foo FooArray[b2]; If I change Foo later, the above rules would make LongArray and FooArray different types. If I change b2 later, the same must happen. In other words, the fact that LongArray and FooArray are similar is coincidental. I would go even further with this rule, and declare that different arrays are always different, no matter what their shape. If we go back to your A, B, and C example, I would apply the same reasoning to arrays: typedef long A[10]; typedef long B[10]; typedef B C; Here, A and B would be different, and A and C would be equivalent. > Question 2: If two TypeCodes with RepositoryIds have the same > RepositoryId, do we require equivalent to also check their > components as > well? Doing this is slower, but more robust in face of IDL version > skew. I would strongly argue that if the repository IDs are the same, then the types can be assumed the same. There are dozens of things in CORBA that will break badly if you allow repository IDs to go out of synch, so I see no point in even trying to check for this. CORBA assumes a single universal type system, where the same repository IDs mean the same thing everywhere. We might as well acknowledge that. > Question 3: What should the comparison semantics be if one TypeCode has > a RepositoryId and the other one doesn't, in order to allow the best > interoperability between ORBs supporting the new spec and older ones? > Should we declare the types to be different, or just fall back on a > structural comparison? Because we cannot know what type originally belonged to the type code without the ID, I don't think we can assume that the types are different (because they may have been the same). I would therefore fall back to structural comparison. This will occasionally give a false positive. However, giving a false negative would be worse in my opinion, because it would prevent legitimate use of a type that is actually correct. 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 Return-Path: Sender: jon@floorboard.com Date: Mon, 11 May 1998 15:03:21 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Update(2) on TypeCode comparison [I missed a few bullets in the first message, so here it is again with the added stuff.] Here is the latest version of the TypeCode equality proposal, with a few questions that I'd like some comments on. Please let me (and Tom Rutt) know what your opinion is on this as soon as possible. Proposal: 1. Make RepositoryIds mandatory for struct, union, enum, and alias typecodes. 2. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics: a) If the two TypeCodes are the same primitive type (null, void, short, long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode, longlong, ulonglong, longdouble, wchar) then equivalent() returns true. b) If the two TypeCodes are string, wstring or fixed with the same parameters (bounds, digits or scale) then equivalent() returns true. c) If the two TypeCodes are both arrays or both sequences, with the same bounds and component type, then equivalent() returns true. [See Question 1, below.] d) If the two TypeCodes are both structs, unions, enums or aliases, and they have the same RepositoryId, then equivalent() returns true. [See Questions 2 and 3, below.] e) If one of the two TypeCodes is a direct or indirect alias of the other one, then equivalent() returns true(). This means that for the following IDL: typedef Long A; typedef Long B; typedef A C; Long & A are equivalent, Long & B are equivalent, A & C are equivalent, but A & B are not. This seems to be the best compromise between semi-strong typed languages like C and C++ where typedefs do not define new types, and strong typed languages like Ada, where typedefs do define new types. This solution seems to provide the best level of interoperability. f) Otherwise, equivalent() returns false. 3. The ORB uses TypeCode::equivalent for all internal TypeCode comparisons, such as for supporting any and DynAny. 4. If the programmer needs to distinguish between a type and an alias of that type, he can call TypeCode::id() and compare the RepositoryIds. 5. Specifically for DynAny, all DynAny operations do not consider aliases as significant for insertion and extraction operations. The type() operation however, will return the TypeCode with all of the aliases intact, including type() from any DynAny member components. 6. [Optional, we can vote on this one separately.] Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; TypeCode::get_compact_typecode() strips out all optional name & member name fields. TypeCode::get_canonical_typecode() looks up the typecode in the IR and returns the fully fleshed-out typecode. If the IR is unavailable, or does not contain the information needed, the INTF_REPOS system exception is raised. 7. If this proposal is accepted I will propose to the C++ RTF to add the following operation to CORBA::Any: class Any { public: ... void replace_typecode(TypeCode_ptr tc); }; so that you can set a specific typecode for the Any after inserting a value. The operation would throw BAD_TYPECODE if the typecode does not compare "equivalent" to the typecode already in the Any. This allows the programmer to change the typecode from a type to an alias of the type. ---------------------------------------------------------------------------------------- Question 1: What does it mean for the component type of arrays or sequences to be the same? Do we recursively apply equivalent, or is it stricter. For example: typedef long Foo; typedef long LongArray[10]; typedef Foo FooArray[10]; are LongArray and FooArray equivalent or not? Question 2: If two TypeCodes with RepositoryIds have the same RepositoryId, do we require equivalent to also check their components as well? Doing this is slower, but more robust in face of IDL version skew. Question 3: What should the comparison semantics be if one TypeCode has a RepositoryId and the other one doesn't, in order to allow the best interoperability between ORBs supporting the new spec and older ones? Should we declare the types to be different, or just fall back on a structural comparison? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 12 May 1998 10:48:56 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Update(2) on TypeCode comparison On Mon, 11 May 1998, Jonathan Biggar wrote: > 7. If this proposal is accepted I will propose to the C++ RTF to add > the following operation to CORBA::Any: > > class Any { > public: > ... > void replace_typecode(TypeCode_ptr tc); > }; > > so that you can set a specific typecode for the Any after inserting a > value. The operation would throw BAD_TYPECODE if the typecode does not > compare "equivalent" to the typecode already in the Any. This allows > the programmer to change the typecode from a type to an alias of the > type. Jon, I would suggest to overload the already existing type() method instead of calling it replace_typecode(). The semantics would be the same. 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 Return-Path: Date: Mon, 11 May 1998 18:53:29 -0600 From: Javier Lopez-Martin To: jon@floorboard.com, ter@holta.ho.lucent.com Subject: Re: OMG:Update(2) on TypeCode comparison Cc: orb_revision@omg.org Content-Md5: eHavSk/DeqpRAYbKs/naDg== Hi, Here are my comments. Most of them are looking for completeness, adding clarifications, and looking for corner cases. However, I think that the proposal is quite positive (and light-years better than what is now in the spec!). > [I missed a few bullets in the first message, so here it is again with > the added stuff.] > > Here is the latest version of the TypeCode equality proposal, with a few > questions that I'd like some comments on. Please let me (and Tom Rutt) > know what your opinion is on this as soon as possible. > > Proposal: > > 1. Make RepositoryIds mandatory for struct, union, enum, and alias > typecodes. What about exceptions, shouldn't their RepositoryIds also be mandatory? > 2. Define a new equivalent operation for TypeCodes: > > pseudo interface TypeCode { > ... > boolean equivalent(in TypeCode other); > ... > }; > > with the following semantics: > > a) If the two TypeCodes are the same primitive type (null, void, > short, > long, ushort, ulong, float, double, boolean, char, octet, any, > TypeCode, > longlong, ulonglong, longdouble, wchar) then equivalent() returns > true. > > b) If the two TypeCodes are string, wstring or fixed with the same > parameters (bounds, digits or scale) then equivalent() returns true. > > c) If the two TypeCodes are both arrays or both sequences, with the > same bounds and component type, then equivalent() returns true. [See > Question 1, below.] The component type should be compared in terms of equivalent() as well. [Note: saying that two typecodes have the "same" component type is not enough, or else we would not be having this discussion :-)] > d) If the two TypeCodes are both structs, unions, enums or aliases, and > they have the same RepositoryId, then equivalent() returns true. [See > Questions 2 and 3, below.] How do you compare exceptions and object reference typecodes? This is not specified in the proposal. > e) If one of the two TypeCodes is a direct or indirect alias of the > other one, then equivalent() returns true(). This means that for > the > following IDL: > > typedef Long A; > typedef Long B; > typedef A C; > > Long & A are equivalent, Long & B are equivalent, A & C are > equivalent, > but A & B are not. This seems to be the best compromise between > semi-strong typed languages like C and C++ where typedefs do not > define > new types, and strong typed languages like Ada, where typedefs do > define > new types. This solution seems to provide the best level of > interoperability. Also, long & C are equivalent, and C & B are not. > f) Otherwise, equivalent() returns false. There is no mention whatsoever of the names in typecodes. Making an explicit mention that names are irrelevant under any circumstances (except equal()) seems important. > 3. The ORB uses TypeCode::equivalent for all internal TypeCode > comparisons, such as for supporting any and DynAny. > > 4. If the programmer needs to distinguish between a type and an > alias > of that type, he can call TypeCode::id() and compare the > RepositoryIds. Or between aliases, or ... In general, for more strict (but different from equal()) comparisons. > 5. Specifically for DynAny, all DynAny operations do not consider > aliases as significant for insertion and extraction operations. The > type() operation however, will return the TypeCode with all of the > aliases intact, including type() from any DynAny member components. What happens when using assign()? According to your proposal, the aliases should not be taken into account. However, I think they should according to equivalent() as well ... There might be other cases where this is needed. [Note: this is implied in #3 above, but the wording here makes it inconsistent at best] > 6. [Optional, we can vote on this one separately.] Define two new > operations on TypeCodes: > > pseudo interface TypeCode { > ... > TypeCode get_compact_typecode(); > TypeCode get_canonical_typecode(); > ... > }; > > TypeCode::get_compact_typecode() strips out all optional name & > member > name fields. TypeCode::get_canonical_typecode() looks up the > typecode > in the IR and returns the fully fleshed-out typecode. If the IR is > unavailable, or does not contain the information needed, the > INTF_REPOS > system exception is raised. You need to mention that names are optional somewhere ... > 7. If this proposal is accepted I will propose to the C++ RTF to add > the following operation to CORBA::Any: > > class Any { > public: > ... > void replace_typecode(TypeCode_ptr tc); > }; > This should be proposed regardless of the outcome of the above, because it also solves the issue of how to add aliases to anys (specially for simple types). > so that you can set a specific typecode for the Any after inserting a > value. It should also be valid before inserting a value. This shouldn't be restricted (except as specified below). > The operation would throw BAD_TYPECODE if the typecode does not > compare "equivalent" to the typecode already in the Any. This > allows > the programmer to change the typecode from a type to an alias of the > type. > > -------------------------------------------------------------------------------- -------- > Question 1: What does it mean for the component type of arrays or > sequences to be the same? Do we recursively apply equivalent, or is > it > stricter. For example: > > typedef long Foo; > typedef long LongArray[10]; > typedef Foo FooArray[10]; > > are LongArray and FooArray equivalent or not? This depends on whether they have the right alias typecode or not. If they have, then the answer is obviously no (because their repository ids are different). If either or both aliases are missing, then in my opinion the answer should be yes. You cannot tell for sure, so better err on giving a false positive (when types are compatible), than on giving a false negative. Note that in Michi's example, the fact that would allow for a definite answer (exactly as Michi proposed) is that the alias typecodes are present or not. However, if aliases are not present, the best you can do is structural comparison, and hope for the best ... NOTE: If the example would have been: typedef long Foo; typedef long Bar typedef Bar BarArray[10]; typedef Foo FooArray[10]; Then: - if all aliases are present, then equivalent() returns false - if no aliases are present in neither, then equivalent() returns true regardless of what we might say about it (both are tk_array{tk_long,10}) - if one of them had aliases and the other didn't, we should err on the positive side, and make equivalent() return true; if not, then we should make Foo and long be different (according to equivalent()), as the situation is parallel. - if the Array aliases are missing, but the component aliases are not, then equivalent() should return false: the component does not compare equivalent(), even though the external level does. > Question 2: If two TypeCodes with RepositoryIds have the same > RepositoryId, do we require equivalent to also check their > components as > well? Doing this is slower, but more robust in face of IDL version > skew. As Michi pointed, this shouldn't be needed. If the same RepId refers to different types in the sending/receiving end, then what would happen to a typed interface using that type? This should be the same situation. Comparing RepIds should be enough. > Question 3: What should the comparison semantics be if one TypeCode has > a RepositoryId and the other one doesn't, in order to allow the best > interoperability between ORBs supporting the new spec and older ones? > Should we declare the types to be different, or just fall back on a > structural comparison? In my opinion, structural comparison. Specially given the fact that aliases are still not mandatory for sequences/arrays and typedefs of simple types (in my opinion, they should be mandatory). Doing structural comparison here would give an equivalent level of "compatibility" between the types than that obtained when aliases are not present (note that the repository id in enums/unions/structs/etc plays the same role, in my opinion, that the first alias of simple types and sequence/array: creating a class of type). Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: From: N.P.Sharman@man0506.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 12 May 1998 10:07:17 +0100 X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 12 May 1998 10:06:38 +0100 X400-Received: by mta hls03 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 12 May 1998 10:12:32 +0100 X400-Received: by mta MAN05C1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 12 May 1998 10:03:09 +0100 X400-Received: by /PRMD=ICL/ADMD=GOLD 400/C=GB/; converted (ia5-text); Relayed; Tue, 12 May 1998 10:04:38 +0100 Date: Tue, 12 May 1998 10:04:38 +0100 X400-Originator: N.P.Sharman@man0506.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000026100000997] X400-Content-Type: P2-1984 (2) Content-Identifier: 997 Alternate-Recipient: Allowed To: jon@floorboard.com Cc: orb_revision@omg.org References: <355775A9.DBEDEB71@floorboard.com> Subject: RE: Update(2) on TypeCode comparison Jon Biggar writes: > [I missed a few bullets in the first message, so here it is again with > the added stuff.] > > Here is the latest version of the TypeCode equality proposal, with a few > questions that I'd like some comments on. Please let me (and Tom Rutt) > know what your opinion is on this as soon as possible. > > Proposal: > > 1. Make RepositoryIds mandatory for struct, union, enum, and alias > typecodes. > Agreed; and for exceptions. > 2. Define a new equivalent operation for TypeCodes: > > pseudo interface TypeCode { > ... > boolean equivalent(in TypeCode other); > ... > }; > > with the following semantics: > > a) If the two TypeCodes are the same primitive type (null, void, > short, > long, ushort, ulong, float, double, boolean, char, octet, any, > TypeCode, > longlong, ulonglong, longdouble, wchar) then equivalent() returns > true. > > b) If the two TypeCodes are string, wstring or fixed with the same > parameters (bounds, digits or scale) then equivalent() returns true. > > c) If the two TypeCodes are both arrays or both sequences, with the > same bounds and component type, then equivalent() returns true. [See > Question 1, below.] > > d) If the two TypeCodes are both structs, unions, enums or aliases, > and > they have the same RepositoryId, then equivalent() returns true. > [See > Questions 2 and 3, below.] > > e) If one of the two TypeCodes is a direct or indirect alias of the > other one, then equivalent() returns true(). This means that for > the > following IDL: > > typedef Long A; > typedef Long B; > typedef A C; > > Long & A are equivalent, Long & B are equivalent, A & C are > equivalent, > but A & B are not. This seems to be the best compromise between > semi-strong typed languages like C and C++ where typedefs do not > define > new types, and strong typed languages like Ada, where typedefs do > define > new types. This solution seems to provide the best level of > interoperability. > This rule means that TypeCode::equivalent() is not an equivalence relationship, which is somewhat counter-intuitive. It seems we want > to strike some sort of compromise between extremely-strongly typed languages, > where alias-like type definitions introduce distinct types, and > less-strongly typed languages like C & C++ (aliases are synonyms), Java (no aliases) and > SmallTalk (not much in the way of static typing). I suggest that we need to decide what the IDL type semantics are; does typedef introduce a distinct type, or merely a notational convenience? If the former, then equivalence() should not "look through" any tk_alias TypeCodes when comparing; if the latter, then comparison should (in principle) strip out all TypeCodes before performing the real check. Note that the "distinct types" semantics doesn't invalid the current mappings for C, C++, Java etc; we just note that we sacrifice a level of static typing in favour of a simpler mapping (in particular, for basic types). On the other hand, the "notational convenience" semantics sits poorly on the Ada mapping; to keep the correspondence between IDL and Ada type names, we impose type- checking hurdles on the Ada programmer that are not mandated by the IDL type model. Pragmatically, I think the suggested rules (a) are inconvenient to implement (you need to check both A alias-of B and B alias-of A) and (b) lead to arbitrary choices about equivalence for more complex types, such as arrays and sequences. I suspect the resulting rules would be confusing for application developers and ORB implementers. > f) Otherwise, equivalent() returns false. > > 3. The ORB uses TypeCode::equivalent for all internal TypeCode > comparisons, such as for supporting any and DynAny. > > 4. If the programmer needs to distinguish between a type and an > alias > of that type, he can call TypeCode::id() and compare the > RepositoryIds. > Not necessary if we adopt "distinct types" semantics. > 5. Specifically for DynAny, all DynAny operations do not consider > aliases as significant for insertion and extraction operations. The > type() operation however, will return the TypeCode with all of the > aliases intact, including type() from any DynAny member components. > > 6. [Optional, we can vote on this one separately.] Define two new > operations on TypeCodes: > > pseudo interface TypeCode { > ... > TypeCode get_compact_typecode(); > TypeCode get_canonical_typecode(); > ... > }; > > TypeCode::get_compact_typecode() strips out all optional name & > member > name fields. TypeCode::get_canonical_typecode() looks up the > typecode > in the IR and returns the fully fleshed-out typecode. If the IR is > unavailable, or does not contain the information needed, the > INTF_REPOS > system exception is raised. > > 7. If this proposal is accepted I will propose to the C++ RTF to > add > the following operation to CORBA::Any: > > class Any { > public: > ... > void replace_typecode(TypeCode_ptr tc); > }; > > so that you can set a specific typecode for the Any after inserting > a > value. The operation would throw BAD_TYPECODE if the typecode does > not > compare "equivalent" to the typecode already in the Any. This > allows > the programmer to change the typecode from a type to an alias of the > type. > Here, we are trying to solve the problem that (in C++ at least) the > type rules of the programming language are weaker than those of IDL, and that we > can't generate distinct operators <<=(Any&,T) and <<=(Any&,V) where typedef > T V. This suggests we need at least one further form of equivalence, say TypeCode::pl_equivalent() ["pl" = "programming language"] which yields > true iff the programming language mappings of the IDL types described by > the TypeCodes are equivalent under the rules of the programming language. > (Of course, this function would give different answers in different > languages.) Other correspondents have, I think, tried to capture this by adding extra parameters to TypeCode::equivalent(). These attempts have tried to keep the meanings of the equivalent() variants programming-language independent, but in this case we are trying to reconcile programming language and IDL semantics and we might as well face up to it. > ---------------------------------------------------------------------------- > ------------ > Question 1: What does it mean for the component type of arrays or > sequences to be the same? Do we recursively apply equivalent, or is it > stricter. For example: > > typedef long Foo; > typedef long LongArray[10]; > typedef Foo FooArray[10]; > > are LongArray and FooArray equivalent or not? > Recursive equivalence is easy to understand and implement. The answer to this question should match the intended semantics of typedef in IDL. > Question 2: If two TypeCodes with RepositoryIds have the same > RepositoryId, do we require equivalent to also check their > components as > well? Doing this is slower, but more robust in face of IDL version > skew. > As a pragmatic issue, comparing RepIds should suffice. > Question 3: What should the comparison semantics be if one TypeCode has > a RepositoryId and the other one doesn't, in order to allow the best > interoperability between ORBs supporting the new spec and older ones? > Should we declare the types to be different, or just fall back on a > structural comparison? > Fall back to structural comparison. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Return-Path: Date: Tue, 12 May 1998 08:44:49 -0400 From: Paul H Kyzivat Organization: NobleNet To: N.P.Sharman@man0506.wins.icl.co.uk CC: jon@floorboard.com, orb_revision@omg.org Subject: Re: Update(2) on TypeCode comparison References: <355775A9.DBEDEB71@floorboard.com> <"997*/I=NP/S=Sharman/OU=man0506/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> N.P.Sharman@man0506.wins.icl.co.uk wrote: [snip] > This rule means that TypeCode::equivalent() is not an equivalence > relationship, which is somewhat counter-intuitive. It seems we want > to strike > some sort of compromise between extremely-strongly typed languages, > where > alias-like type definitions introduce distinct types, and > less-strongly typed > languages like C & C++ (aliases are synonyms), Java (no aliases) and > SmallTalk > (not much in the way of static typing). > > I suggest that we need to decide what the IDL type semantics are; does > typedef > introduce a distinct type, or merely a notational convenience? If the > former, > then equivalence() should not "look through" any tk_alias TypeCodes > when > comparing; if the latter, then comparison should (in principle) strip > out all > TypeCodes before performing the real check. I agree that the ambiguity of typedef semantics in idl is the major issue here. Both interpretations are valuable. Currently the ambiguity of idl is projected into the language mappings. The C/C++ mapping dictates structural equivalence for typedefs of basic types but not for complex types like sequences and arrays. Apparently the other language mappings imply other forms of equivalence for the same idl. I think the real solution is to extend idl to support both kinds explicitly. E.g. typedef A B; synonym A C; Then B could be an entirely new type, while C isn't. This change would unfortunately break the C/C++ mappings for typedef to basic types. To avoid breaking existing mappings it might be necessary to introduce two new statements and deprecate typedef. Paul Return-Path: Sender: jon@floorboard.com Date: Tue, 12 May 1998 10:36:44 -0700 From: Jonathan Biggar To: N.P.Sharman@man0506.wins.icl.co.uk CC: orb_revision@omg.org Subject: Re: Update(2) on TypeCode comparison References: <355775A9.DBEDEB71@floorboard.com> <"997*/I=NP/S=Sharman/OU=man0506/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> N.P.Sharman@man0506.wins.icl.co.uk wrote: > > 1. Make RepositoryIds mandatory for struct, union, enum, and > alias > > typecodes. > > > Agreed; and for exceptions. Exceptions and Object References are already mandatory. > This rule means that TypeCode::equivalent() is not an equivalence > relationship, which is somewhat counter-intuitive. It seems we want > to strike > some sort of compromise between extremely-strongly typed languages, > where > alias-like type definitions introduce distinct types, and > less-strongly typed > languages like C & C++ (aliases are synonyms), Java (no aliases) and > SmallTalk > (not much in the way of static typing). Right. We need a compromise in order to work reasonably well with strong-typed and less strong-typed languages. Another consideration is interoperability between older ORBs and newer ones that implement the new type equivalence definition. > I suggest that we need to decide what the IDL type semantics are; does typedef > introduce a distinct type, or merely a notational convenience? If the former, > then equivalence() should not "look through" any tk_alias TypeCodes when > comparing; if the latter, then comparison should (in principle) strip out all > TypeCodes before performing the real check. > > Note that the "distinct types" semantics doesn't invalid the current mappings > for C, C++, Java etc; we just note that we sacrifice a level of static typing > in favour of a simpler mapping (in particular, for basic types). On the other > hand, the "notational convenience" semantics sits poorly on the Ada mapping; > to keep the correspondence between IDL and Ada type names, we impose type- > checking hurdles on the Ada programmer that are not mandated by the IDL type > model. Unfortunately, it would invalidate the C++ mapping, which is our largest constituency (with Java gaining). If I say: // IDL typedef long Height; typedef long Weight; these are mapped to: // C++ typedef long Height; CORBA::TypeCode_ptr _tc_Height; typedef long Weight; CORBA::TypeCode_ptr _tc_Weight; The two typecodes are are different, but the underlying C++ types are the same. In particular, the problem with the C++ mapping, is that right now: CORBA::Any a1, a2; a1 << (Height)0; a2 << (Weight)0; will give you exactly the same thing in both a1, and a2, namely [CORBA::_tc_long, 0]. Most people out there probably would like to be able to distinguish between an any containing a Height, and an any containing a Weight, but with CORBA 2.2 C++, you can't portably do that. We also have an interoperability problem, say between C++ and Ada, because C++ will always send a long in the Any, and Ada will be expecting a Height or Weight, and will fail. This compromise seems to best fit the issues of backwards and forwards compatiblity, as well as interoperability between strong-typed and less strong-typed languages. > Pragmatically, I think the suggested rules (a) are inconvenient to implement > (you need to check both A alias-of B and B alias-of A) and (b) lead to > arbitrary choices about equivalence for more complex types, such as arrays and > sequences. I suspect the resulting rules would be confusing for application > developers and ORB implementers. Yes, you do have to check A alias-of B and B alias-of A, but that isn't too hard. I am trying to make the rules bullet-proof, so that it won't be too confusing. I don't see any holes in the rules for arrays and sequences (other than Question 1, on which I have two different opinions already, but we can nail that down), can you enlighten us with the holes you think are there? > > f) Otherwise, equivalent() returns false. > > > > 3. The ORB uses TypeCode::equivalent for all internal TypeCode > > comparisons, such as for supporting any and DynAny. > > > > 4. If the programmer needs to distinguish between a type and an > alias > > of that type, he can call TypeCode::id() and compare the > RepositoryIds. > > > Not necessary if we adopt "distinct types" semantics. > > > 5. Specifically for DynAny, all DynAny operations do not consider > > aliases as significant for insertion and extraction operations. > The > > type() operation however, will return the TypeCode with all of the > > aliases intact, including type() from any DynAny member > components. > > > > 6. [Optional, we can vote on this one separately.] Define two > new > > operations on TypeCodes: > > > > pseudo interface TypeCode { > > ... > > TypeCode get_compact_typecode(); > > TypeCode get_canonical_typecode(); > > ... > > }; > > > > TypeCode::get_compact_typecode() strips out all optional name & > member > > name fields. TypeCode::get_canonical_typecode() looks up the > typecode > > in the IR and returns the fully fleshed-out typecode. If the IR > is > > unavailable, or does not contain the information needed, the > INTF_REPOS > > system exception is raised. > > > > 7. If this proposal is accepted I will propose to the C++ RTF to > add > > the following operation to CORBA::Any: > > > > class Any { > > public: > > ... > > void replace_typecode(TypeCode_ptr tc); > > }; > > > > so that you can set a specific typecode for the Any after > inserting a > > value. The operation would throw BAD_TYPECODE if the typecode > does not > > compare "equivalent" to the typecode already in the Any. This > allows > > the programmer to change the typecode from a type to an alias of > the > > type. > > > Here, we are trying to solve the problem that (in C++ at least) the > type rules > of the programming language are weaker than those of IDL, and that > we can't > generate distinct operators <<=(Any&,T) and <<=(Any&,V) where > typedef T V. > This suggests we need at least one further form of equivalence, say > TypeCode::pl_equivalent() ["pl" = "programming language"] which > yields true > iff the programming language mappings of the IDL types described by > the > TypeCodes are equivalent under the rules of the programming > language. (Of > course, this function would give different answers in different > languages.) You don't need this. I can easily determine programming language equivalence, typically at compile time, just by attempting an assignment. > Other correspondents have, I think, tried to capture this by adding extra > parameters to TypeCode::equivalent(). These attempts have tried to keep the > meanings of the equivalent() variants programming-language independent, but in > this case we are trying to reconcile programming language and IDL semantics > and we might as well face up to it. The proposal has rejected adding parameters to TypeCode equivalent because we want to try really hard to agree on a single equivalence mechanism that makes the best compromise. Added arguments to equivalent makes the problem difficult, because the ORB does internal typecode equivalance comparisons, and we couldn't come up with an acceptible API to set what equivalence parameters the ORB would use that didn't run into problems. Do you set it globally for the ORB, separately for a thread, or procedure, or object, or any, or what? Each choice seemed right in different circumstances, and it was too messy to deal with. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: To: Michi Henning cc: Javier Lopez-Martin , kukura@iona.com, jon@floorboard.com, orb_revision@omg.org Subject: Re: [Fwd: More on Typecode equality] Date: Wed, 13 May 1998 16:59:28 +1000 From: Keith Duddy Hi all, I hope this isn't too far behind the current state of the discussion... >On Fri, 1 May 1998, Javier Lopez-Martin wrote: > >> The notification service uses a filtering grammar (based on the trader >> grammar, and called an "extended trader grammar") that allows for >> creating filtering expressions bases solely on position; with this >> type of filtering, there is no problem as names are not taken into >> consideration. But it also allows for creating filtering expressions >> in a more "human readable" format, using names. > >Hmmm... In fairness, I would say that the Notification Service puts all >the emphasis on the human-readable format. The positional notation was >added as an afterthought after I started screaming and pointed out that >the names and member names are optional... That's right - the thinking behind it is that a consumer who specifies a name-based constraint will typically have stub code for (and perhaps an IR reference to the definition of) the types that they intend to match against and extract from the Any that they receive from the Notification Service. I always envisaged that the positional-based constraint would be automatically generated using the name-based constraint and the "fully populated" Typecode or a local IR by some tool or vendor addition to the service. I envisage that application developers would write the name-based constraint, submit it to some conversion method and then register the resulting positional constraint with the service so that values coming through the Notification Channel in Anys that have Typecode without names can be matched. >> So, if repository ids are made mandatory, and names can be obtained from a >> local IR (to the notification service), the full functionality can be >> achieved without any compromise or change to the currently adopted (or >> should I say in the process of being adopted, as the fax vote has not >> yet completed) Notification service. > >Only one glitch here - the Interface Repository is an optional component >of CORBA. Also, I think it is a bit naive to expect to deploy a serious >(large scale) notification service and to expect that service to have >all event types available in an Interface Repository. In effect, federated >Notification Services would then only be reliable if all channels in the >federation agreed to either use the same IFR, or all IFR's for those channels >were synchronised. I don't expect that a Notification Service would typically consult an IFR at all. The constraints that it's filters contain will be matched to the best of their ability depending on the form of the constraint (named or positional) and the content of the Typecodes in the Anys that it processes. To some extent this means that consumers must anticipate whether or not the Typecodes will contain names, and this would inform their decision about whether to translate the constraint into the positional notation (or to use Structured Events - which always contain the names in a Name Value pair ;-) K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: To: Javier Lopez-Martin cc: michi@dstc.edu.au, jon@floorboard.com, orb_revision@omg.org Subject: Re: [Fwd: More on Typecode equality] Date: Wed, 13 May 1998 17:05:09 +1000 From: Keith Duddy On the issue of aliases: >> > I agree with this, but would make the rule about aliases comparison >> > slightly different: >> > - two types are considered equivalent (with respect to aliases) if >> > either both types are the same, or one is an alias of the other >> > (the number of alias levels is irrelevant here); this definition >> > should be applied recursively as well, to compare components of >> > the type. >> > >> > This would make: >> > >> > typedef double Weight; >> > typedef double Height; >> > typedef Height Tall; >> > >> > double <-> Weight >> > double <-> Height <-> Tall >> > >> > BUT: >> > >> > Weight <-/-> Height >> > Weight <-/-> Tall >> >> Hmmm... This strikes as too complicated and too difficult to define/impleme nt. > >I don't think it is too complicated: >- take both typecodes, and collect all aliases into a sequence for each type; > then compare both sequences starting at the end; if when the shorter > sequence is exahusted, the types still compare as equal, then they are > equivalent; if at least one sequence is empty, then structural typecode > comparison should be performed (I don't think I need to define this). I prefer the algoritm that we hand-code at the moment (which would deliver equality for all of the types above). That is: no_alias_eq(T1, T2) = equal(unwind_all_aliases(T1), unwind_all_aliases(T2)) where unwind_all_aliases means repeatedly extracting the TypeCode inside a tk_alias until the kind is not tk_alias. K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: From: N.P.Sharman@man0506.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 13 May 1998 11:49:03 +0100 X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 13 May 1998 11:42:23 +0100 X400-Received: by mta hls03 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 13 May 1998 11:48:29 +0100 X400-Received: by mta MAN05C1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 13 May 1998 11:38:00 +0100 X400-Received: by /PRMD=ICL/ADMD=GOLD 400/C=GB/; converted (ia5-text); Relayed; Wed, 13 May 1998 11:38:37 +0100 Date: Wed, 13 May 1998 11:38:37 +0100 X400-Originator: N.P.Sharman@man0506.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000026100001000] X400-Content-Type: P2-1984 (2) Content-Identifier: 1000 Alternate-Recipient: Allowed To: jon@floorboard.com Cc: orb_revision@omg.org References: <355888AC.9DEFF8FB@floorboard.com> Subject: RE(2): Update(2) on TypeCode comparison Jon Biggar wrote: > N.P.Sharman@man0506.wins.icl.co.uk wrote: --- (snip) --- > > This rule means that TypeCode::equivalent() is not an equivalence > > relationship, which is somewhat counter-intuitive. It seems we > > want to strike some sort of compromise between extremely-strongly > > typed languages, where alias-like type definitions introduce > > distinct types, and less-strongly typed languages like C & C++ > > (aliases are synonyms), Java (no aliases) and SmallTalk (not much > > in the way of static typing). > > Right. We need a compromise in order to work reasonably well with > strong-typed and less strong-typed languages. Another consideration > > is interoperability between older ORBs and newer ones that implement > > the new type equivalence definition. > My point is that TypeCode::equivalent() should reflect the semantics of IDL's type rules, i.e. whether or not IDL typedef introduces a distinct type (a la Ada) or whether it introduces a synonym for the same type (a la C++). The current spec doesn't say (and we all agree that TypeCode::equal() doesn't help), although perhaps the choice of C++-style syntax and the name tk_alias hints at the "synonym" interpretation?). > > I suggest that we need to decide what the IDL type semantics are; > > does typedef introduce a distinct type, or merely a notational > > convenience? If the former, then equivalence() should not "look > > through" any tk_alias TypeCodes when comparing; if the latter, > > then comparison should (in principle) strip out all TypeCodes > > before performing the real check. Note that the "distinct types" > > semantics doesn't invalid the current mappings for C, C++, Java > > etc; we just note that we sacrifice a level of static typing in > > favour of a simpler mapping (in particular, for basic types). On > > the other hand, the "notational convenience" semantics sits poorly > > > on the Ada mapping; to keep the correspondence between IDL and Ada > > type names, we impose type-checking hurdles on the Ada programmer > > that are not mandated by the IDL type model. > > Unfortunately, it would invalidate the C++ mapping, which is our > largest constituency (with Java gaining). If I say: > > // IDL > typedef long Height; > typedef long Weight; > > these are mapped to: > > // C++ > typedef long Height; > CORBA::TypeCode_ptr _tc_Height; > typedef long Weight; > CORBA::TypeCode_ptr _tc_Weight; > > The two typecodes are are different, but the underlying C++ types > are the same. In particular, the problem with the C++ mapping, is > that right now: > > CORBA::Any a1, a2; > > a1 << (Height)0; > a2 << (Weight)0; > > will give you exactly the same thing in both a1, and a2, namely > [CORBA::_tc_long, 0]. > Most people out there probably would like to be able to distinguish > between an any containing a Height, and an any containing a Weight, > but with CORBA 2.2 C++, you can't portably do that. We also have an > interoperability problem, say between C++ and Ada, because C++ will > always send a long in the Any, and Ada will be expecting a Height or > Weight, and will fail. This compromise seems to best fit the issues > > of backwards and forwards compatiblity, as well as interoperability > between strong-typed and less strong-typed languages. > Yes, with the current C++ mapping, the C++ types CORBA::Long, Height and Weight are indistinguishable, regardless of the definition of TypeCode::equivalent(). Let's assume that we want: _tc_Length->equivalent (_tc_Height) == FALSE This the case for both your proposal and the straight "distinct types" rule. In my C++ application, I can gaily add Heights and Weights regardless. Is the C++ mapping then broken? No; we have merely taken the pragmatic decision to alias these types to a built-in arithmetic type, to save having to generate separate classes, with lots of arithmetic and conversion operators. (BTW, these particular examples suggest you have "dimensional analysis" in mind. This is harder than it looks; what should Length*Length yield? Not another Length, surely; it should be Area or Length-squared.) > > Pragmatically, I think the suggested rules (a) are inconvenient to > > implement (you need to check both A alias-of B and B alias-of A) > > and (b) lead to arbitrary choices about equivalence for more > > complex types, such as arrays and sequences. I suspect the > > resulting rules would be confusing for application developers and > > ORB implementers. > > Yes, you do have to check A alias-of B and B alias-of A, but that > isn't too hard. I am trying to make the rules bullet-proof, so that > > it won't be too confusing. I don't see any holes in the rules for > arrays and sequences (other than Question 1, on which I have two > different opinions already, but we can nail that down), can you > enlighten us with the holes you think are there? I don't know whether there are any holes; my concern is that the proposal is more complex than it need be. You can see two sensible alternatives for sequence/array aliases; other correspondents have tried to resolve the choice by reasoning about the intent of the IDL's author. The more complex the rule, the more users are liable to misread it and be surprised by the results. Given that we want Height and Length to be distinct (IDL) types, even though we accept that they get mapped to the same C++ type, what do we gain from making them both (IDL) equivalent to long? The answer, I guess, is so that we can reset a C++ Any's TypeCode to something more specific than _tc_long, but I argue that the question of IDL type equivalence should be decided independently of a C++ implementation problem. If you accept that, then I would argue for a simple definition of typedef semantics, either "synonym" or "distinct types". But of course, we do still need to solve the C++ problem ... --- (snip) --- > > > 7. If this proposal is accepted I will propose to the C++ RTF > > > to add the following operation to CORBA::Any: > > > > > > class Any { > > > public: > > > ... > > > void replace_typecode(TypeCode_ptr tc); > > > }; > > > > > > so that you can set a specific typecode for the Any after > > > inserting a value. The operation would throw BAD_TYPECODE if > > > the typecode does not compare "equivalent" to the typecode > > > already in the Any. This allows the programmer to change the > > > typecode from a type to an alias of the type. > > > > Here, we are trying to solve the problem that (in C++ at least) > > the type rules of the programming language are weaker than those > > of IDL, and that we can't generate distinct operators <<=(Any&,T) > > and <<=(Any&,V) where typedef T V. This suggests we need at least > > > one further form of equivalence, say TypeCode::pl_equivalent() > > ["pl" = "programming language"] which yields true iff the > > programming language mappings of the IDL types described by the > > TypeCodes are equivalent under the rules of the programming > > language. (Of course, this function would give different answers > > in different languages.) > > You don't need this. I can easily determine programming language > equivalence, typically at compile time, just by attempting an > assignment. > But I'm proposing that TypeCode::pl_equivalent() is used by Any::replace_typecode() [or the Any::type(TypeCode) overload], not by users directly. Under my suggested "distinct type" rule, for example, > straight TypeCode::equivalent() simply won't work here: it wouldn't allow: // C++ Any a; Height h = 42; a <<= h; // whoops, "a" contains _tc_long! a.type (_tc_Height) // aah, that's better! You're probably right in suggesting the pl_equivalent() isn't much use outside this context, so you could just fold it's definition into the precondition of Any::type(TypeCode): If the Any object contains a TypeCode, then the current and supplied TypeCodes must describe IDL types that are mapped to the same C++ type undersupplied TypeCode must describe an IDL type that are mapped to the same C++ type; otherwise the BAD_TYPECODE exception is raised. The definition of the >>= extraction operators also need to reflect this > > Other correspondents have, I think, tried to capture this by > > adding extra parameters to TypeCode::equivalent(). These attempts > > > have tried to keep the meanings of the equivalent() variants > > programming-language independent, but in this case we are trying > > to reconcile programming language and IDL semantics and we might > > as well face up to it. > > The proposal has rejected adding parameters to TypeCode equivalent > because we want to try really hard to agree on a single equivalence > mechanism that makes the best compromise. Added arguments to > equivalent makes the problem difficult, because the ORB does > internal typecode equivalance comparisons, and we couldn't come up > with an acceptible API to set what equivalence parameters the ORB > would use that didn't run into problems. Do you set it globally for > > the ORB, separately for a thread, or procedure, or object, or any, > or what? Each choice seemed right in different circumstances, and > it was too messy to deal with. > Yes, different parameterisations are a bad idea, for all these reasons. So I restate my suggestion: * define the semantics of IDL type equivalence, including IDL typedef, independently of target language; * for clarity, IDL type equivalence should be an equivalence relation, and should have a simple definition as possible; * define TypeCode::equivalent() to reflect this decision; * recognize that, for given languages, distinct IDL types may map to the same programming language type (or vice versa) and that problems like C++ Any-insertion will need resolving in programming-language- specific ways. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Nick Sharman ICL Object Software Laboratories Return-Path: Date: Wed, 13 May 1998 09:16:24 -0400 From: Paul H Kyzivat Organization: NobleNet To: N.P.Sharman@man0506.wins.icl.co.uk CC: jon@floorboard.com, orb_revision@omg.org Subject: Re: Update(2) on TypeCode comparison References: <355888AC.9DEFF8FB@floorboard.com> <"1000*/I=NP/S=Sharman/OU=man0506/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> N.P.Sharman@man0506.wins.icl.co.uk wrote: [snip] > Yes, different parameterisations are a bad idea, for all these > reasons. So I restate my suggestion: > > * define the semantics of IDL type equivalence, including IDL typedef, > independently of target language; > > * for clarity, IDL type equivalence should be an equivalence > relation, and should have a simple definition as possible; > > * define TypeCode::equivalent() to reflect this decision; > > * recognize that, for given languages, distinct IDL types may map to > the same programming language type (or vice versa) and that problems > like C++ Any-insertion will need resolving in programming-language- > specific ways. This seems to be a reasonable compromise. Note that for c++ a solution is already in place for the builtin types (the to_octet, from_octet, and other similar types), and for arrays (the *_forany types). The to_octet solution doesn't scale because all those types are declared within the scope of Any, but the *_forany approach could be followed for any types that are synonymous in their c++ mapping. Paul Return-Path: Date: Wed, 13 May 1998 10:22:02 -0700 From: jon@floorboard.com (Jon Biggar) To: orb_revision@omg.org Subject: Draft 3 of the TypeCode equivalence proposal Ok, here is version 3 of the proposal, with some edits. I am going to send out a separate message shortly identifying the different point of view about alias equivalence, along with my views on the pros and cons of each approach. Proposal: 1. Make RepositoryIds mandatory for all TypeCodes that have them. 2. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics: a) If the two TypeCodes are the same primitive type (null, void, short, long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode, longlong, ulonglong, longdouble, wchar) then equivalent() returns true. b) If the two TypeCodes are string, wstring or fixed with the same parameters (bounds, digits or scale) then equivalent() returns true. c) If the two TypeCodes are both arrays or both sequences, with the same bounds and their component types are equivalent(), then equivalent() returns true. d) If the two TypeCodes are both object references, return true if the their RepositoryIds are the same. e) If the two TypeCodes are both structs, exceptions, unions, enums or aliases, and they have the same RepositoryId, then equivalent() returns true. Note in this case that member TypeCodes are not compared. f) If either or both of the TypeCodes have an empty RepositoryId, then equivalent() falls back to a structural comparison, and returns true if all members of the two TypeCodes also are equivalent(). g) If one of the two TypeCodes is a direct or indirect alias of the other one, then equivalent() returns true(). This means that for the following IDL: typedef Long A; typedef Long B; typedef A C; Long & A, Long & B, Long & C and A & C are equivalent, but A & B and B & C are not. h) Otherwise, equivalent() returns false. 3. The ORB uses TypeCode::equivalent for all internal TypeCode comparisons, such as for supporting any and DynAny. 4. If the programmer needs to distinguish between a type and an alias of that type, he can call TypeCode::id() and compare the RepositoryIds. 5. Specifically for DynAny, all DynAny insert & get operations do not consider aliases as significant. The type() operation however, will return the TypeCode with all of the aliases intact, including type() from any DynAny member components. DynAny::assign() and DynAny::from_any compare the internal TypeCode of the DynAny with the Typecode of its argument using TypeCode::equivalent() and raise Invalid if equivalent() returns false. 6. [Optional, we can vote on this one separately.] Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; TypeCode::get_compact_typecode() strips out all optional name & member name fields. TypeCode::get_canonical_typecode() looks up the typecode in the IR and returns the fully fleshed-out typecode. If the IR is unavailable, or does not contain the information needed, the INTF_REPOS system exception is raised. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Wed, 13 May 1998 11:29:41 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Positions on TypeCode comparison I consider the lack of a defined TypeCode comparison function for the ORB to be a serious impediment to interoperability and portability of applications. I am driving this discussion so that there is a chance we can come to a consensus opinion in the RTF soon, preferably before the May 18 deadline. Here are the points that I think we all agree on: 1. The concept of IDL type and TypeCode equivalence needs to be well defined in a language independent way. 2. Since different languages have different models of types, IDL type equivalence should be defined inside the "sweet spot" that still allows for reasonable language mappings and in particular, as small a perturbation to the existing language mappings as we can find, however, some changes to the language mappings may be needed. 3. Interoperability with previous versions of the ORB and language mapping specs also need to be considered. 4. The ORB specification needs to define a single comparison operation for TypeCodes that can be used internally by the ORB to support any and DynAny, and by extension the DII and DSI. Defining multiple comparison operations or providing parameters to the comparison operation that change its semantics are considered bad, because of the difficulties of guaranteeing which comparison operation is used at different points in the ORB. 5. If a particular application needs stronger or weaker comparison functions, it should be possible to start with the "standard" comparison function and then add an additional application defined comparison to get the required semantics. 6. Since the Interface Repository defines the name & member_name fields of TypeCodes (and IR interfaces) to be optional, and potentially different from IR to IR, the name and member_name fields should not be considered in comparing TypeCodes. This means that the TypeCode::equal() operation is not useful, and we need a new comparison operation. Ok, given the above, there is one particular sticky point that is preventing consensus: how to treat aliases (aka "typedef") when comparing TypeCodes. Here is some example IDL that will be used for the following discussion: // IDL typedef long A; typedef long B; typedef A C; typedef long LongArray[2]; typedef A AArray[2]; typedef B BArray[2]; typedef C CArray[2]; There are two main points of view, and a middle ground compromise proposal. The first point of view is that typedef defines a new type, and all of the above IDL types are distinct and do not compare equivalent. I'll call this view "distinct types". The second point of view is that typedef merely introduces a synonym name, so types long, A, B, and C are all equivalent, and all of the Array types are equivalent also. I'll call this view "aliases not significant". The compromise point of view defines types to be equivalent if one of the types is directly or indirectly an alias of the other, but not if both are different aliases of a common ancestor. In this view, long & A, long & B, long & C and A & C are equivalent, but A & B and B & C are not. Likewise, LongArray & AArray, LongArray & BArray, LongArray & CArray and AArray & CArray are equivalent, while AArray & BArray and BArray & CArray are not. [I personally don't like this view for array (or sequence) comparison much, but making it stricter would overly complicate the definition of equivalence.] I'll call this view "compromise". Here are the pros and cons for each view as I see them: Pros of the "distinct types" view: + Simplest to define the comparison function. + Allows applications to distinguish between typedefs of primitive types easily, which may be important for a large class of applications using any. Cons of the "distinct types" view: + Does not match the weaker type models of C, C++, Java or Smalltalk well. + Would require updates to the above language mappings to make sure that programmers can ensure the right TypeCodes are inserted into anys. + Causes problems with interoperability between different language mappings and with older ORB and language mapping versions. Pros of the "aliases not significant" view: + Almost as easy to define the comparison function. + Minimizes interoperability problems between languages and/or older ORB or language mappings. Cons of the "aliases not significant" view: + Makes it difficult (if not impossible) for applications to distinguish between aliases of primitive types. + Doesn't match the Ada language mapping at all, since Ada requires typedefs to be mapped to distinct types. Pros of the "compromise" view: + Strikes the best practical balance between strong-typed and weak-typed language models. + Allows the application to distinguish between different aliases of primitive types. + Should provide for reasonable interoperability between language mappings and between older ORB and language mapping versions. Cons of the "compromise" view: + Most complicated comparison function. Might be confusing for novices. [I do want to state here that the definition I have been proposing is designed to be complete and accurate, rather than easy to understand. I believe that an easy to understand explanation of the rules is possible.] + Sits in the middle, not a intellectually "clean" type equivalence model. I prefer the "compromise" view, but I would settle for the "aliases not significant" view if that appears to be the consensus. I think that the "distinct types" view poses too many problems with interoperability and code portability to be viable. Please respond with your comments and positions quickly, so we can see if a consensus is pssible. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: To: Jonathan Biggar cc: orb_revision@omg.org, ter@holta.ho.lucent.com Subject: Re: Update on TypeCode equality proposal Date: Thu, 14 May 1998 18:14:21 +1000 From: Keith Duddy Hi Jonathan, This looks like a really good concrete proposal (and although I'm not actually a memeber of this RTF) howver I think the typecode aliasing is too complex, and that the relationship to the type systems of the mapped languages is a red herring.... >e) If one of the two TypeCodes is a direct or indirect alias of the >other one, then equivalent() returns true(). This means that for the >following IDL: > >typedef Long A; >typedef Long B; >typedef A C; I still want to know if the completely unaliased types are the same. i.e. if I extract the value into a long can I put it back into a C, or an A or a B (using whatever coercion my programming language requires). I'd like to have the CORBA type system somewhat more abstract than the programming languages. Another 3c (which is now about US$0.02).... >Question 1: What does it mean for the component type of arrays or >sequences to be the same? Do we recursively apply equivalent, or is it >stricter. For example: > >typedef long Foo; >typedef long LongArray[10]; >typedef Foo FooArray[10]; > >are LongArray and FooArray equivalent or not? According to my prefered alias comparison scheme - YES... I'm interested in knowing that I can use a FooArray as a long array (modulo coercion), not which typedef was defined in terms of which other... Your scheme (e) above puts a great deal more onus on IDL writers to typdef from a root type than I think it should. >Question 2: If two TypeCodes with RepositoryIds have the same >RepositoryId, do we require equivalent to also check their components as >well? Doing this is slower, but more robust in face of IDL version >skew. I'd say NO until we approach versioning properly.... >Question 3: What should the comparison semantics be if one TypeCode has >a RepositoryId and the other one doesn't, in order to allow the best >interoperability between ORBs supporting the new spec and older ones? >Should we declare the types to be different, or just fall back on a >structural comparison? If equal is still around to do the structural comparison then I'd say return false from equivalent... cheers, K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: Sender: jon@floorboard.com Date: Thu, 14 May 1998 08:32:20 -0700 From: Jonathan Biggar To: Keith Duddy CC: orb_revision@omg.org, ter@holta.ho.lucent.com Subject: Re: Update on TypeCode equality proposal References: <199805140814.SAA06259@piglet.dstc.edu.au> Keith Duddy wrote: > > Hi Jonathan, > > This looks like a really good concrete proposal (and although I'm > not > actually a memeber of this RTF) howver I think the typecode aliasing > is too complex, and that the relationship to the type systems of the > mapped languages is a red herring.... > > >e) If one of the two TypeCodes is a direct or indirect alias of > the > >other one, then equivalent() returns true(). This means that for > the > >following IDL: > > > >typedef Long A; > >typedef Long B; > >typedef A C; > > I still want to know if the completely unaliased types are the same. > i.e. if I extract the value into a long can I put it back into a C, > or > an A or a B (using whatever coercion my programming language > requires). I'd like to have the CORBA type system somewhat more > abstract than the programming languages. This proposal does not affect the type compatibility as defined by the language mappings. So if your language mapping defines A, B & C to be compatible, like C, C++, Java and Smalltalk, then you can assign between these values at will. For Ada, however, the IDL types map to different Ada types, so you must use explicit type coercion. > Another 3c (which is now about US$0.02).... > > >Question 1: What does it mean for the component type of arrays or > >sequences to be the same? Do we recursively apply equivalent, or > is it > >stricter. For example: > > > >typedef long Foo; > >typedef long LongArray[10]; > >typedef Foo FooArray[10]; > > > >are LongArray and FooArray equivalent or not? > > According to my prefered alias comparison scheme - YES... I'm > interested in knowing that I can use a FooArray as a long array > (modulo coercion), not which typedef was defined in terms of which > other... Your scheme (e) above puts a great deal more onus on IDL > writers to typdef from a root type than I think it should. The way the proposal is now written, it uses equivalent to compare the component types of the arrays, but any alias definitions at the top level still have effect. So for the example above, LongArray & FooArray are not equivalent, since they are different aliases, with different RepositoryIds, and one is not an alias of the other. However, if you stripped off the alias TypeCodes, then the underlying array TypeCodes would be equivalent(). > >Question 2: If two TypeCodes with RepositoryIds have the same > >RepositoryId, do we require equivalent to also check their > components as > >well? Doing this is slower, but more robust in face of IDL version > >skew. > > I'd say NO until we approach versioning properly.... That appears to be the consensus. > >Question 3: What should the comparison semantics be if one TypeCode has > >a RepositoryId and the other one doesn't, in order to allow the best > >interoperability between ORBs supporting the new spec and older ones? > >Should we declare the types to be different, or just fall back on a > >structural comparison? > > If equal is still around to do the structural comparison then I'd say > return false from equivalent... Equal is around, but it doesn't do structural comparison as defined, it does exact comparison, including the name and member_name fields. This has been universally recognized as less than useful, since name and member_name fields are optional, and even when they have values, their values are dependent on the Interface Repository you got them from. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: To: N.P.Sharman@man0506.wins.icl.co.uk cc: jon@floorboard.com, orb_revision@omg.org Subject: Re: RE(2): Update(2) on TypeCode comparison Date: Fri, 15 May 1998 12:00:50 +1000 From: Keith Duddy Hi again, >> N.P.Sharman@man0506.wins.icl.co.uk wrote: > >> > This rule means that TypeCode::equivalent() is not an equivalence >> > relationship, which is somewhat counter-intuitive. It seems we >> > want to strike some sort of compromise between extremely-strongly >> > typed languages, where alias-like type definitions introduce >> > distinct types, and less-strongly typed languages like C & C++ >> > (aliases are synonyms), Java (no aliases) and SmallTalk (not much >> >> > in the way of static typing). >> >> Right. We need a compromise in order to work reasonably well with >> strong-typed and less strong-typed languages. Another >> consideration >> is interoperability between older ORBs and newer ones that >> implement >> the new type equivalence definition. I have modified my opinion somewhat. I think that the languages can inform the semantics we want for IDL - but I think we need to choose what we want for IDL and then see if it's implementable (and how cleanly so)... and revisit the proposal if it isn't practical... >> Unfortunately, it would invalidate the C++ mapping, which is our >> largest constituency (with Java gaining). If I say: >> >> // IDL >> typedef long Height; >> typedef long Weight; >> >> these are mapped to: >> >> // C++ >> typedef long Height; >> CORBA::TypeCode_ptr _tc_Height; >> typedef long Weight; >> CORBA::TypeCode_ptr _tc_Weight; >> >> The two typecodes are are different, but the underlying C++ types >> are the same. In particular, the problem with the C++ mapping, is >> that right now: >> >> CORBA::Any a1, a2; >> >> a1 << (Height)0; >> a2 << (Weight)0; >> >> will give you exactly the same thing in both a1, and a2, namely >> [CORBA::_tc_long, 0]. >> Most people out there probably would like to be able to distinguish >> between an any containing a Height, and an any containing a Weight, >> >> but with CORBA 2.2 C++, you can't portably do that. We also have >> an >> interoperability problem, say between C++ and Ada, because C++ will >> always send a long in the Any, and Ada will be expecting a Height >> or >> Weight, and will fail. This compromise seems to best fit the >> issues >> of backwards and forwards compatiblity, as well as interoperability >> >> between strong-typed and less strong-typed languages. I don't agree - given the proposed semantics the choices seem to be: Say to C++ programmers "You must specially populate the typecodes of your anys with tk_alias typecodes if you want the semantics of C++ Typecode::equivalent() to reflect the IDL semantics", Or, ditch the <<= insertion and create named methods called insert_Height(), insert_Long() etc... I prefer the approach of winding back all aliases to the type underneath as this is very easy to implement in the Ada mapping (and in C++ you only get the type underneath if you use the any <<= operators anyway), but also because it reflect the notion of "typedef" and "alias" much better. >> > > 7. If this proposal is accepted I will propose to the C++ RTF >> > > to add the following operation to CORBA::Any: >> > > >> > > class Any { >> > > public: >> > > ... >> > > void replace_typecode(TypeCode_ptr tc); >> > > }; Yuk! I would strongly suggest that we don't force programmers to put typecodes into Anys for aliases... regards, K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: Date: Tue, 30 Jun 1998 20:00:37 -0400 From: Jonathan Biggar Organization: Floorboard Software To: orb_revision@omg.org Subject: New TypeCode comparison proposal I have rethought my proposal on TypeCode comparison, and I have decided to drop the idea of defining two different aliases of a TypeCode as being not equivalent in favor of the simpler solution that aliases are not considered significant at all for TypeCode comparison. Hopefully this will make it easier to reach a consensus. Instead, I will concentrate on making sure that the language mappings contain enough mechanism so that applications which need a stronger TypeCode comparison test can do so. Points 1 through 9 need to be considered as one unit. Point 10 can be voted on independently, but does provide a useful capability for controlling the size and content of TypeCodes. Proposal: 1. Make RepositoryIds mandatory for all TypeCodes that have them. [This was done by the previous core RTF. I am just reiterating it here for completeness.] 2. All TypeCode constants generated by the IDL compiler, as well as all TypeCodes returned by the Interface Repository must include alias TypeCodes wherever a typedef declaration appears in the original IDL source. 3. Each IDL programming language mapping must provide a mechanism for the programmer to ensure that values of the IDL any type contain the exact typecode desired by the programmer. 4. The name() and member_name() fields of the TypeCode are for documentary purposes only, and are never considered significant when comparing TypeCodes. 5. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics: a) If the two TypeCodes are the same primitive type (null, void, short, long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode, longlong, ulonglong, longdouble, wchar) then equivalent() returns true. b) If the two TypeCodes are string, wstring or fixed with the same parameters (bounds, digits or scale) then equivalent() returns true. c) If the two TypeCodes are both arrays or both sequences, with the same bounds and their component types are equivalent(), then equivalent() returns true. d) If the two TypeCodes are both object references, return true if the their RepositoryIds are the same. e) If the two TypeCodes are both structs, exceptions, unions, enums or aliases, and they have the same RepositoryId, then equivalent() returns true. Note in this case that member TypeCodes are not compared. f) If either or both of the TypeCodes have an empty RepositoryId, then equivalent() falls back to a structural comparison, and returns true if all members of the two TypeCodes also are equivalent(). This case will only occur when interoperating with an older ORB that does not yet require RepositoryIds as mandatory for these TypeCodes. Note that the name() and member_name() fields are not used in this comparison. g) Otherwise, equivalent() returns false. 6. The ORB uses TypeCode::equivalent for all internal TypeCode comparisons, such as for supporting any (and thus DII and DSI) and DynAny. 7. If the programmer needs to distinguish between a type and/or different aliases of that type, he can call TypeCode::id() and compare the RepositoryIds. 8. All DynAny insert & get operations do not consider aliases as significant. The type() operation however, will return the TypeCode with all of the aliases intact, including type() from any DynAny member components. DynAny::assign() and DynAny::from_any compare the internal TypeCode of the DynAny with the TypeCode of its argument using TypeCode::equivalent() and raise Invalid if equivalent() returns false. 9. The TypeCode::equal() operation is not used internally by the ORB and is deprecated. 10. Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; TypeCode::get_compact_typecode() strips out all optional name & member name fields. TypeCode::get_canonical_typecode() looks up the TypeCode in the Interface Repository and returns the fully fleshed-out TypeCode. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by calling TypeCode::get_canonical_typecode() on each member TypeCode of the original TypeCode. If the Interface Repository is unavailable, or does not contain the information needed, the call raises the INTF_REPOS system exception. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 1 Jul 1998 11:02:02 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal On Tue, 30 Jun 1998, Jonathan Biggar wrote: > I have rethought my proposal on TypeCode comparison, and I have > decided > to drop the idea of defining two different aliases of a TypeCode as > being not equivalent in favor of the simpler solution that aliases > are > not considered significant at all for TypeCode comparison. > Hopefully > this will make it easier to reach a consensus. Instead, I will > concentrate on making sure that the language mappings contain enough > mechanism so that applications which need a stronger TypeCode > comparison > test can do so. > > Points 1 through 9 need to be considered as one unit. Point 10 can > be > voted on independently, but does provide a useful capability for > controlling the size and content of TypeCodes. I like this proposal. In particular, I agree with the idea that preserving aliases is a language mapping issue. I'm not sure that point 10 is really necessary, but I don't have any objections either. 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 Return-Path: Date: Tue, 30 Jun 1998 19:23:46 -0600 From: Javier Lopez-Martin To: orb_revision@omg.org, jon@floorboard.com Subject: Re: New TypeCode comparison proposal Content-Md5: NU375ldgImdwHrls+5BQDg== Hi Jon, I'm glad to see this back on the table, as I think it is really important. Some minor comments are inline: > I have rethought my proposal on TypeCode comparison, and I have decided > to drop the idea of defining two different aliases of a TypeCode as > being not equivalent in favor of the simpler solution that aliases are > not considered significant at all for TypeCode comparison. Hopefully > this will make it easier to reach a consensus. Instead, I will > concentrate on making sure that the language mappings contain enough > mechanism so that applications which need a stronger TypeCode comparison > test can do so. I'd prefer the stricter type checking that we originally talked about, but if this makes it through, I'd rather have it done this way that not done because of lack of consensus ... > Points 1 through 9 need to be considered as one unit. Point 10 can be > voted on independently, but does provide a useful capability for > controlling the size and content of TypeCodes. > > Proposal: > > 1. Make RepositoryIds mandatory for all TypeCodes that have them. [This > was done by the previous core RTF. I am just reiterating it here for > completeness.] What happens with typecodes created by the ORB::create_* operations? I think they should be mandatory there as well, but I think that this editorial change was not done, and in fact, the current (2.2+) wording of the repository ids being mandatory is a bit ambiguous in my opinion. We should make the text more explicit. > 2. All TypeCode constants generated by the IDL compiler, as well as all > TypeCodes returned by the Interface Repository must include alias > TypeCodes wherever a typedef declaration appears in the original IDL > source. Good! > 3. Each IDL programming language mapping must provide a mechanism for > the programmer to ensure that values of the IDL any type contain the > exact typecode desired by the programmer. So this means that there must be a language-specific mechanism to replace a typecode by an equivalent one? Again, GOOD! > 4. The name() and member_name() fields of the TypeCode are for > documentary purposes only, and are never considered significant when > comparing TypeCodes. > > 5. Define a new equivalent operation for TypeCodes: > > pseudo interface TypeCode { > ... > boolean equivalent(in TypeCode other); > ... > }; > > with the following semantics: Prior to doing any of the things below, you must strip off all alias typecodes, to support the semantics you outlined in the beginning of your message. > a) If the two TypeCodes are the same primitive type (null, void, short, > long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode, > longlong, ulonglong, longdouble, wchar) then equivalent() returns true. To allow for extensibility in the future, how about: a) If the two Typecodes are primitive (empty parameter sequence), and they have the same Kind, then equivalent() returns true. > b) If the two TypeCodes are string, wstring or fixed with the same > parameters (bounds, digits or scale) then equivalent() returns true. Also here, to allow for extensibility: b) If the two Typecodes are simple, and they have the same Kind and the same parameters, then equivalent returns true. > c) If the two TypeCodes are both arrays or both sequences, with the > same bounds and their component types are equivalent(), then > equivalent() returns true. > > d) If the two TypeCodes are both object references, return true if > the > their RepositoryIds are the same. > > e) If the two TypeCodes are both structs, exceptions, unions, enums > or > aliases, and they have the same RepositoryId, then equivalent() > returns > true. Note in this case that member TypeCodes are not compared. At this point, you do not have aliases to compare ... or else, the comparison rules above should be explicit about stripping aliases in each rule. And if you do, then you have to explicitly define the way an alias is considered (and when). > f) If either or both of the TypeCodes have an empty RepositoryId, then > equivalent() falls back to a structural comparison, and returns true if > all members of the two TypeCodes also are equivalent(). This case will > only occur when interoperating with an older ORB that does not yet > require RepositoryIds as mandatory for these TypeCodes. Note that the > name() and member_name() fields are not used in this comparison. It is obvious, but we need to explain what is "structural comparison" of typecodes ... > g) Otherwise, equivalent() returns false. Alternatively, the comparison rules could look something like the following (in my opinion simpler): a) Strip off all alias typecodes before attempting comparison b) If the kinds of the two typecodes differ, equivalent() returns false. c) If the kinds are equal, and the typecodes have an empty parameter list, equivalent() returns true. d) If the typecodes have a simple parameter list, equivalent() returns true if the parameter lists of both typecodes are equal, false otherwise. e) If the typecodes have a complex parameter list, equivalent() returns true if the RepositoryIds of both typecodes are equal, false if they are different. In case at least one of the typecodes with a complex parameter list has an empty (or no) RepositoryId, then the result of equivalent() is the same as performing an structural comparison, defined as follows: - all name and member_name parameters are ignored (they always compare as equal) - simple type parameters are compared for equality (length, count ...) - Typecode parameters are compared by equivalent() rules > 6. The ORB uses TypeCode::equivalent for all internal TypeCode > comparisons, such as for supporting any (and thus DII and DSI) and > DynAny. > > 7. If the programmer needs to distinguish between a type and/or > different aliases of that type, he can call TypeCode::id() and > compare > the RepositoryIds. > > 8. All DynAny insert & get operations do not consider aliases as > significant. The type() operation however, will return the TypeCode > with all of the aliases intact, including type() from any DynAny > member > components. DynAny::assign() and DynAny::from_any compare the > internal > TypeCode of the DynAny with the TypeCode of its argument using > TypeCode::equivalent() and raise Invalid if equivalent() returns > false. The aliases will be there if they were in the inserted typecode in the first place ... Also, if you use from_any or assign, which typecode is kept after the operation completes: the one that was originally in the DynAny, or the one of the inserted/assigned Any/DynAny? I assume that the one originally in the DynAny should not be replaced, but we must be explicit about it. > 9. The TypeCode::equal() operation is not used internally by the ORB > and is deprecated. And its behaviour remains absolutely unchanged: it performs an exact match, including names, member_names and the like. > 10. Define two new operations on TypeCodes: > > pseudo interface TypeCode { > ... > TypeCode get_compact_typecode(); > TypeCode get_canonical_typecode(); > ... > }; > > TypeCode::get_compact_typecode() strips out all optional name & > member > name fields. TypeCode::get_canonical_typecode() looks up the > TypeCode > in the Interface Repository and returns the fully fleshed-out > TypeCode. > If the top level TypeCode does not contain a RepositoryId, (such as > array and sequence TypeCodes, or TypeCodes from older ORBs), then a > new > TypeCode is constructed by calling > TypeCode::get_canonical_typecode() on > each member TypeCode of the original TypeCode. If the Interface > Repository is unavailable, or does not contain the information > needed, > the call raises the INTF_REPOS system exception. You are assuming that the only way to obtain the full TypeCode back is from the IR. While this is certainly a likely situation, some ORBs might choose to use other internal mechanisms to regain such information, without the need of an IFR. We should not preclude such implementations. > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Hope this helps. I will send, in a separate email, a complement to this regarding the "yet more compact" encoding proposal that I sent some days ago, aligning it with this one. I'm sendind it in a separate email because it is a separate issue, and can be treated independently. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Date: Tue, 30 Jun 1998 22:37:24 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <35997C25.CEA88C19@floorboard.com> I believe the proposed form of TypeCode comparison is useful, and therefore I support most of this proposal. This does not mean that other forms of TypeCode comparison might not also be useful. I oppose point 9 because I believe that comparing whether all operations will return the same result may also be useful in some cases, and therefore equal() should not be deprecated or even banished from internal use. Finally, I am leaning towards opposing point 10. The proposed get_canonical_typecode() operation would take a significant amount of code to implement and signficant time to execute. This functionality would better be provided via an operation on CORBA::Repository. This would not bloat the ORB core as much, and far fewer remote calls would be needed to canonize a TypeCode. Also, there would be a well-defined source for the names. -Bob Jonathan Biggar wrote: > > I have rethought my proposal on TypeCode comparison, and I have > decided > to drop the idea of defining two different aliases of a TypeCode as > being not equivalent in favor of the simpler solution that aliases > are > not considered significant at all for TypeCode comparison. > Hopefully > this will make it easier to reach a consensus. Instead, I will > concentrate on making sure that the language mappings contain enough > mechanism so that applications which need a stronger TypeCode > comparison > test can do so. > > Points 1 through 9 need to be considered as one unit. Point 10 can > be > voted on independently, but does provide a useful capability for > controlling the size and content of TypeCodes. > > Proposal: > > 1. Make RepositoryIds mandatory for all TypeCodes that have > them. [This > was done by the previous core RTF. I am just reiterating it here > for > completeness.] > > 2. All TypeCode constants generated by the IDL compiler, as well as > all > TypeCodes returned by the Interface Repository must include alias > TypeCodes wherever a typedef declaration appears in the original IDL > source. > > 3. Each IDL programming language mapping must provide a mechanism > for > the programmer to ensure that values of the IDL any type contain the > exact typecode desired by the programmer. > > 4. The name() and member_name() fields of the TypeCode are for > documentary purposes only, and are never considered significant when > comparing TypeCodes. > > 5. Define a new equivalent operation for TypeCodes: > > pseudo interface TypeCode { > ... > boolean equivalent(in TypeCode other); > ... > }; > > with the following semantics: > > a) If the two TypeCodes are the same primitive type (null, void, > short, > long, ushort, ulong, float, double, boolean, char, octet, any, > TypeCode, > longlong, ulonglong, longdouble, wchar) then equivalent() returns > true. > > b) If the two TypeCodes are string, wstring or fixed with the same > parameters (bounds, digits or scale) then equivalent() returns true. > > c) If the two TypeCodes are both arrays or both sequences, with the > same bounds and their component types are equivalent(), then > equivalent() returns true. > > d) If the two TypeCodes are both object references, return true if > the > their RepositoryIds are the same. > > e) If the two TypeCodes are both structs, exceptions, unions, enums > or > aliases, and they have the same RepositoryId, then equivalent() > returns > true. Note in this case that member TypeCodes are not compared. > > f) If either or both of the TypeCodes have an empty RepositoryId, > then > equivalent() falls back to a structural comparison, and returns true > if > all members of the two TypeCodes also are equivalent(). This case > will > only occur when interoperating with an older ORB that does not yet > require RepositoryIds as mandatory for these TypeCodes. Note that > the > name() and member_name() fields are not used in this comparison. > > g) Otherwise, equivalent() returns false. > > 6. The ORB uses TypeCode::equivalent for all internal TypeCode > comparisons, such as for supporting any (and thus DII and DSI) and > DynAny. > > 7. If the programmer needs to distinguish between a type and/or > different aliases of that type, he can call TypeCode::id() and > compare > the RepositoryIds. > > 8. All DynAny insert & get operations do not consider aliases as > significant. The type() operation however, will return the TypeCode > with all of the aliases intact, including type() from any DynAny > member > components. DynAny::assign() and DynAny::from_any compare the > internal > TypeCode of the DynAny with the TypeCode of its argument using > TypeCode::equivalent() and raise Invalid if equivalent() returns > false. > > 9. The TypeCode::equal() operation is not used internally by the > ORB > and is deprecated. > > 10. Define two new operations on TypeCodes: > > pseudo interface TypeCode { > ... > TypeCode get_compact_typecode(); > TypeCode get_canonical_typecode(); > ... > }; > > TypeCode::get_compact_typecode() strips out all optional name & > member > name fields. TypeCode::get_canonical_typecode() looks up the > TypeCode > in the Interface Repository and returns the fully fleshed-out > TypeCode. > If the top level TypeCode does not contain a RepositoryId, (such as > array and sequence TypeCodes, or TypeCodes from older ORBs), then a > new > TypeCode is constructed by calling > TypeCode::get_canonical_typecode() on > each member TypeCode of the original TypeCode. If the Interface > Repository is unavailable, or does not contain the information > needed, > the call raises the INTF_REPOS system exception. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Return-Path: Date: Tue, 30 Jun 1998 20:57:27 -0600 From: Javier Lopez-Martin To: orb_revision@omg.org, jon@floorboard.com, javier@cnd.hp.com Subject: Re: New TypeCode comparison proposal Content-Md5: QDvT6kt3hltGydNazL3cDA== A couple more comments I forgot in my prior email: > > 10. Define two new operations on TypeCodes: > > > > pseudo interface TypeCode { > > ... > > TypeCode get_compact_typecode(); > > TypeCode get_canonical_typecode(); > > ... > > }; > > > > TypeCode::get_compact_typecode() strips out all optional name & > member > > name fields. TypeCode::get_canonical_typecode() looks up the > TypeCode > > in the Interface Repository and returns the fully fleshed-out > TypeCode. > > If the top level TypeCode does not contain a RepositoryId, (such > as > > array and sequence TypeCodes, or TypeCodes from older ORBs), then > a new > > TypeCode is constructed by calling > TypeCode::get_canonical_typecode() on > > each member TypeCode of the original TypeCode. If the Interface > > Repository is unavailable, or does not contain the information > needed, > > the call raises the INTF_REPOS system exception. No mention is made of what happens to aliases in the typecodes when applying these operations. I would suggest that text would be added so that they remain intact with these operations (no aliases are stripped or introduced by these operations). Another global issue: if this is going to CORBA 2.3 (as I hope it does!), then the new typecodes introduced by OBV should be taken into consideration, and added to this discussion in the relevant places. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Date: Tue, 30 Jun 1998 23:26:23 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Bob Kukura CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <35997C25.CEA88C19@floorboard.com> <3599A0E4.E35FC7C4@iona.com> Bob Kukura wrote: > Finally, I am leaning towards opposing point 10. The proposed > get_canonical_typecode() operation would take a significant amount > of > code to implement and signficant time to execute. This > functionality > would better be provided via an operation on CORBA::Repository. > This > would not bloat the ORB core as much, and far fewer remote calls > would > be needed to canonize a TypeCode. Also, there would be a > well-defined > source for the names. This is a pretty good suggestion. If others think this is reasonable, then we could leave the get_compact_typecode() operation on TypeCode, and move the get_canonical_typecode() to CORBA::Repository as: TypeCode get_canonical_typecode(in TypeCode tc); -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 30 Jun 1998 23:36:31 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Javier Lopez-Martin CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <199807010123.AA151126226@ovdm40.cnd.hp.com> Javier Lopez-Martin wrote: > Alternatively, the comparison rules could look something like the > following (in my opinion simpler): > > a) Strip off all alias typecodes before attempting comparison > > b) If the kinds of the two typecodes differ, equivalent() returns > false. > > c) If the kinds are equal, and the typecodes have an empty parameter > list, > equivalent() returns true. > > d) If the typecodes have a simple parameter list, equivalent() > returns > true if the parameter lists of both typecodes are equal, false > otherwise. > > e) If the typecodes have a complex parameter list, equivalent() > returns > true if the RepositoryIds of both typecodes are equal, false if > they are different. In case at least one of the typecodes with a > complex parameter list has an empty (or no) RepositoryId, then > the result of equivalent() is the same as performing an > structural > comparison, defined as follows: > > - all name and member_name parameters are ignored (they always > compare > as equal) > - simple type parameters are compared for equality (length, count > ...) > - Typecode parameters are compared by equivalent() rules I like your algorithm better than mine. Consider my steps replaced by yours. > > 8. All DynAny insert & get operations do not consider aliases as > > significant. The type() operation however, will return the > TypeCode > > with all of the aliases intact, including type() from any DynAny > member > > components. DynAny::assign() and DynAny::from_any compare the > internal > > TypeCode of the DynAny with the TypeCode of its argument using > > TypeCode::equivalent() and raise Invalid if equivalent() returns > false. > > The aliases will be there if they were in the inserted typecode in > the > first place ... > > Also, if you use from_any or assign, which typecode is kept after > the > operation completes: the one that was originally in the DynAny, or > the > one of the inserted/assigned Any/DynAny? I assume that the one > originally > in the DynAny should not be replaced, but we must be explicit about > it. Yes, I think that once the DynAny has been created, its acquired TypeCode shouldnever change. > > 9. The TypeCode::equal() operation is not used internally by the ORB > > and is deprecated. > > And its behaviour remains absolutely unchanged: it performs an exact match, > including names, member_names and the like. > > > 10. Define two new operations on TypeCodes: > > > > pseudo interface TypeCode { > > ... > > TypeCode get_compact_typecode(); > > TypeCode get_canonical_typecode(); > > ... > > }; > > > > TypeCode::get_compact_typecode() strips out all optional name & member > > name fields. TypeCode::get_canonical_typecode() looks up the TypeCode > > in the Interface Repository and returns the fully fleshed-out TypeCode. > > If the top level TypeCode does not contain a RepositoryId, (such as > > array and sequence TypeCodes, or TypeCodes from older ORBs), then a new > > TypeCode is constructed by calling TypeCode::get_canonical_typecode() on > > each member TypeCode of the original TypeCode. If the Interface > > Repository is unavailable, or does not contain the information needed, > > the call raises the INTF_REPOS system exception. > > You are assuming that the only way to obtain the full TypeCode back is > from the IR. While this is certainly a likely situation, some ORBs might > choose to use other internal mechanisms to regain such information, > without the need of an IFR. We should not preclude such implementations. Ok, change it to say that it looks it up from the IR or other ORB implementation specific method, as long as that method would return the same result. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 30 Jun 1998 23:37:46 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Javier Lopez-Martin CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <199807010257.AA155881846@ovdm40.cnd.hp.com> Javier Lopez-Martin wrote: > A couple more comments I forgot in my prior email: > > > > 10. Define two new operations on TypeCodes: > > > > > > pseudo interface TypeCode { > > > ... > > > TypeCode get_compact_typecode(); > > > TypeCode get_canonical_typecode(); > > > ... > > > }; > > > > > > TypeCode::get_compact_typecode() strips out all optional name & member > > > name fields. TypeCode::get_canonical_typecode() looks up the TypeCode > > > in the Interface Repository and returns the fully fleshed-out TypeCode. > > > If the top level TypeCode does not contain a RepositoryId, (such as > > > array and sequence TypeCodes, or TypeCodes from older ORBs), then a new > > > TypeCode is constructed by calling TypeCode::get_canonical_typecode() on > > > each member TypeCode of the original TypeCode. If the Interface > > > Repository is unavailable, or does not contain the information needed, > > > the call raises the INTF_REPOS system exception. > > No mention is made of what happens to aliases in the typecodes when > applying these operations. I would suggest that text would be added so > that they remain intact with these operations (no aliases are stripped v> or introduced by these operations). I had assumed that by only stating that the name & member_name fields were affected, that alias TypeCodes would remain intact. If you think we need to say so explicity, that's ok. > Another global issue: if this is going to CORBA 2.3 (as I hope it does!), > then the new typecodes introduced by OBV should be taken into consideration, > and added to this discussion in the relevant places. True.-- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Wed, 1 Jul 1998 10:56:03 -0600 From: Javier Lopez-Martin To: javier@cnd.hp.com, paulk@noblenet.com Subject: Re: New compact TypeCode proposal Cc: orb_revision@omg.org, interop@omg.org Content-Md5: 4VtlCyFkBvAPeRxtvhA3mA== Ok Paul, You have raised very significant comments. I'll try to address what I can, but I'm thinking some of this on the fly, so I might say something wild. > I have embedded comments below > > Javier Lopez-Martin wrote: > > > > Hi all, > > > > This is a resend of issue 1531 (Typecodes too long), currently > > assigned > > to Interop but also relevant here in ORB revision. > > > > This builds on the proposal that Jon Biggar has just made on > typecode > > comparison, and relies on some of his proposals to solve some > issues. > > > > Here it goes: > > > > A new typecode kind is introduced, called "tk_implicit" (subject > to > > name > > change if appropriate). This typecode would be encoded as a > complex > > typecode, with a single parameter, the Repository ID (as follows): > > > > TCKind Integer Value Type Parameters > > > > > > ---------------------------------------------------------------------------- > > tk_implicit ?? complex string (repository ID) > > > > > > ---------------------------------------------------------------------------- > > > > This typecode could be used as a replacement for a tk_struct, > > tk_union, > > tk_enum or tk_except typecode, where the typecode may be > reconstructed > > by application defined mechanisms or by accessing a properly > > configured > > interface repository. > > Do you mean "application defined mechanisms", or do you mean "ORB > specific mechanisms"? > > It is usually/often the ORB that needs this information (e.g. for > marshalling) so application defined mechanisms aren't especially > helpful. I don't see a problem in marshalling (I can think of ways to implement the marshalling part relatively easily), but I see the problem in unmarshalling. Specifically, when the ORB receives this from the wire, there is no way to calculate the proper size of the value (I'm thinking of an Any being sent in an operation) without knowledge of the underlying type. Unless, of course, the value was an encapsulation ... (or any other mechanism that would allow for direct pass-through to the application). Assumming that direct pass-through is possible, then the application code could "know" what the type of the received Any is (say, because it came in a NVPair, or by other app mechanisms), and extract the Any into an appropriately typed variable. Equivalence could be calculated (because of the RepositoryID matches), and therefore type safety could be maintained; the unmarshalling could happen at the time of extraction, once the full typecode is known. > > The semantics of this typecode are that the Repository ID uniquely > > identifies > > the corresponding type, and therefore it is enough to reconstruct > a > > full > > typecode if needed, or to verify type equivalence. This proposal > does > > not try to address the situations that might arise in cases where > both > > ends of a communication do not agree on the Repository IDs for a > type, > > or more importantly, think that two different types have the same > > Repository ID; these situations are considered a mis-configuration > > problem, to be solved by other means. > > > > The Repository Id is mandatory, and is EXACTLY the same as the rep > id > > of > > the original (non-implicit) type. This type could be one of > > tk_struct, > > tk_union, tk_enum or tk_except. Specifically, usage of this > mechanism > > is disallowed for tk_objref (no gains, and might create problems > in > > other > > areas) and for tk_alias (not significant in comparisons); if the > > aliases > > are important for an application, they might be applied to this > > typecode > > the same way they would to any other typecode. > > > > Another operation, besides those defined in the proposal on > typecode > > equivalence made by Jon Bigger, would be added to the TypeCode > pseudo > > interface: > > > > > 10. Define two new operations on TypeCodes: > > > > > > pseudo interface TypeCode { > > > ... > > > TypeCode get_compact_typecode(); > > > TypeCode get_canonical_typecode(); > > > > TypeCode get_implicit_typecode(); > > > > > ... > > > }; > > > > > > TypeCode::get_compact_typecode() strips out all optional name & > > member > > > name fields. TypeCode::get_canonical_typecode() looks up the > > TypeCode > > > in the Interface Repository and returns the fully fleshed-out > > TypeCode. > > > If the top level TypeCode does not contain a RepositoryId, (such > as > > > array and sequence TypeCodes, or TypeCodes from older ORBs), > then a > > new > > > TypeCode is constructed by calling > > TypeCode::get_canonical_typecode() on > > > each member TypeCode of the original TypeCode. If the Interface > > > Repository is unavailable, or does not contain the information > > needed, > > > the call raises the INTF_REPOS system exception. > > > > TypeCode::get_implicit_typecode would return the tk_implicit > > equivalent > > of the current typecode, if it is the appropriate kind (tk_struct, > > tk_union, tk_enum or tk_except), ignoring aliases. If the base > > typecode > > is not one of the appropriate kinds, then a copy of the same > typecode > > is > > returned. Whatever tk_alias typecodes may be present in the > original > > typecode are preserved in the (new) implicit typecode. > > > > An application willing to use this typecode would have to > explicitly > > use this typecode (by means that would be language mapping > dependent) > > whenever sending a typecode accross an interface (either directly, > or > > within a CORBA::Any). The receiving side might reject the value > with > > a MARSHALL exception if this new typecode kind is unknown, or if > the > > repository id/type is not recognized by the ORB (and required); if > > this is the case, the sender should be ready to resend the > operation, > > this time with a full typecode. > > Do you mean that the receiving ORB should only be prepared to > unmarshal > Any values containing this kind of typecode if it happens to have > the > repository id handy? And that the sending ORB need not do anything > special about the MARSHAL exception - that it is up to the sending > application to retry the request if such an exception is received? > If > so, then I think this results in an undesirable blurring of the > division > of responsibility between the ORB and the application program. My intention here was to make this feature as much transparent to ORB implementations as possible, and to keep it small and simple. Also, I don't want to impact people that don't want to use this feature in any significant way (if at all). But I see what you are saying, and I agree with the overall criticism. > In any case, whether it is the ORB or the application that does the > retry, I don't think this works. What happens if a typecode is sent > as > part of an OUT argument (or worse yet, as part of an exception > return)? > Then there is no way to learn that the recipient couldn't process it > and > retry. Yes, I thought about this, and decided that if the application takes the risk to do this (send an implicit typecode in an OUT or exception return), they should be aware of the possible consequences ... > So, I don't think this can be an optional feature, unless it is > negotiated between orbs. > > Also, while I would very much like to have compressed typecodes, I > don't > think this is the right way to get them. It raises the possibility > that > a receiving ORB, in the midst of doing marshalling, may need to > consult > an IR in order to get the information needed to finish > marshalling. I > think this is a very undesirable state of affairs. > > I might change my position on this if the encoding of Any was > changed so > that it was possible to take an Any off the wire without > understanding > the typecode. I agree with this last statement. For this to work properly, as you already pointed out, the Any must be taken off the wire without knowing about the typecode, and unmarshall if and when required by the application (at the time of value extraction from the Any, for example). A possible way to achieve this, without breaking the current encoding rules, would be to make the value in an Any to be within an encapsulation IF the typecode was implicit; this would be very easy for the sending side, and would allow the receiving side to pass the value up to the application. But this would create two alternative encodings for Any: one with typecode followed by value, and another with implicit typecode followed by encapsulated value ... not ideal. Anyhow, I see there are still too many open points in this, and we will not be able to clean them all, and formalize it enough to be put into 2.3. So, let's not waste more time on this for 2.3, and save this issue for later, looking at it together with other (in my opinion, required) changes ... Thanks for your comments and time, Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 2 Jul 1998 10:59:31 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Javier Lopez-Martin , orb_revision@omg.org Subject: Re: New TypeCode comparison proposal On Tue, 30 Jun 1998, Jonathan Biggar wrote: > Javier Lopez-Martin wrote: > > > Alternatively, the comparison rules could look something like the > > following (in my opinion simpler): > > > > [...] > > I like your algorithm better than mine. Consider my steps replaced > by yours. Hi, Tom Rutt, Keith Duddy, and myself just talked about this. We think that Jon's equivalent operation with Javier's modifications looks good. We'd like to suggest one minor refinement. Javier's change strips aliases before starting the comparison. This is good, because it reduces false negatives, and I can still us the id() operations to do fancy stuff with aliases, (e.g. to distinguish weight from height). We should formalize the "alias stripping" a bit more. We think the pseudo-code for step (a) would look like this: CORBA::TypeCode_var tcv1 = ...; // Get initial type code 1 CORBA::TypeCode_var tcv2 = ...; // Get initial type code 2 while (tcv1->kind() == tk_alias) tcv1 = tcv1->content_type(); while (tcv2->kind() == tk_alias) tcv2 = tcv2->content_type(); // Now start remainder of comparison... This strips off the first level of aliases until for each type code, something that is not an alias is encountered. This is sufficient to establish equivalence. Stripping "inner", nested aliases off wouldn't achieve anything, because if there were differing inner aliases, the two type codes by definition cannot belong to the same IDL type (must have come from different IDL definitions). We think the above should be spelled out, to make it clear what "stripping" of aliases means. Regardless of whether you agree with the above or not, we also would like to suggest a slight change as to how names (if present) are used in comparisons. Basically, we are suggesting that if both type codes have names, then the names should be compared. Again, the reasoning is that if the names are different, by definition, the type codes cannot denote the same IDL type (otherwise members would have the same name). If either or both typecodes don't have names, then the comparison is true for those names. To illustrate, the following holds for names: "ABC" == "ABC" "ABC" != "DEF" "" == "ABC" "ABC" == "" "" == "" The motivation for this is to eliminate false positives. If two type codes have different names for some members, they can't be the same type code. Or, to put this differently, if names are present in both type codes, there is no good reason to ignore perfectly good information to get a better comparison. Tom also would like to withdraw the suggestion that names should be mandatory in type codes -- instead, they are still optional. The names, if present, are used to eliminate false positives, no more. 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 Return-Path: Date: Wed, 1 Jul 1998 19:50:42 -0600 From: Javier Lopez-Martin To: jon@floorboard.com, michi@dstc.edu.au Subject: Re: New TypeCode comparison proposal Cc: javier@cnd.hp.com, orb_revision@omg.org Content-Md5: KRxHYg1ct8C1ECk6xyQCBQ== > On Tue, 30 Jun 1998, Jonathan Biggar wrote: > > > Javier Lopez-Martin wrote: > > > > > Alternatively, the comparison rules could look something like > the > > > following (in my opinion simpler): > > > > > > [...] > > > > I like your algorithm better than mine. Consider my steps > replaced by yours. > > > Hi, > > Tom Rutt, Keith Duddy, and myself just talked about this. We think > that > Jon's equivalent operation with Javier's modifications looks > good. We'd > like to suggest one minor refinement. > > Javier's change strips aliases before starting the comparison. This > is > good, because it reduces false negatives, and I can still us the > id() > operations to do fancy stuff with aliases, (e.g. to distinguish > weight > from height). We should formalize the "alias stripping" a bit more. > We think the pseudo-code for step (a) would look like this: > > CORBA::TypeCode_var tcv1 = ...; // Get initial type code 1 > CORBA::TypeCode_var tcv2 = ...; // Get initial type code 2 > > while (tcv1->kind() == tk_alias) > tcv1 = tcv1->content_type(); > > while (tcv2->kind() == tk_alias) > tcv2 = tcv2->content_type(); > > // Now start remainder of comparison... > > This strips off the first level of aliases until for each type code, > something > that is not an alias is encountered. This is sufficient to establish > equivalence. Stripping "inner", nested aliases off wouldn't achieve > anything, > because if there were differing inner aliases, the two type codes by > definition cannot belong to the same IDL type (must have come from > different > IDL definitions). > > We think the above should be spelled out, to make it clear what > "stripping" > of aliases means. I agree with this mecanism for stripping outermost aliases. However, regarding the stricter inner comparison, remember that any time an inner typecode is compared (the only such case is where at least one repository id is missing from a complex typecode), they are compared using equivalent(), and therefore this whole algorithm is applied, stripping inner aliases before attempting inner typecode comparisons. I don't think this was what you intended, but this is what is in the proposal (and I think is the right thing to do). > Regardless of whether you agree with the above or not, we also would like > to suggest a slight change as to how names (if present) are used in > comparisons. > > Basically, we are suggesting that if both type codes have names, then > the names should be compared. Again, the reasoning is that if the names > are different, by definition, the type codes cannot denote the same IDL > type (otherwise members would have the same name). > > If either or both typecodes don't have names, then the comparison is > true for those names. To illustrate, the following holds for names: > > "ABC" == "ABC" > "ABC" != "DEF" > "" == "ABC" > "ABC" == "" > "" == "" > > The motivation for this is to eliminate false positives. If two type codes > have different names for some members, they can't be the same type code. > Or, to put this differently, if names are present in both type codes, > there is no good reason to ignore perfectly good information to get > a better comparison. > > Tom also would like to withdraw the suggestion that names should be mandatory > in type codes -- instead, they are still optional. The names, if present, > are used to eliminate false positives, no more. I cannot agree with this at all, given the "locality" that is intended to names. I know, I also think it does not make sense to translate an operation name to a different language to the one used when it was defined, but this is what the IR chapter says. And I don't see any reason why we should restrict this. The relevant section of the spec follows (extracted from CORBA 2.2, page 8-38, section on Typecodes in the IR chapter): " The name operation can also be invoked on object reference, structure, union, enumeration, alias, and exception TypeCodes. It returns the simple name identifying the type within its enclosing scope. Since names are local to a Repository, the name returned from a TypeCode may not match the name of the type in any particular Repository, and may even be an empty string. The member_count and member_name operations can be invoked on structure, union, and enumeration TypeCodes. Member_count returns the number of members constituting the type. Member_name returns the simple name of the member identified by index. Since names are local to a Repository, the name returned from a TypeCode may not match the name of the member in any particular Repository, and may even be an empty string. " The important thing here is "Since names are local to a Repository, the name returned from a TypeCode may not match the name ...". With the above interpretation, names cannot be used for a safe comparison on type equivalence. They must be compared by equal(), because the semantics of equal() are different from equivalent(). If we were to accept this proposal, we would have to rephrase and rethink this in the IR thoroughly ... and we would be loosing some flexibility for no good reason, in my opinion. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 2 Jul 1998 12:12:57 +1000 (EST) From: Michi Henning To: Javier Lopez-Martin cc: jon@floorboard.com, orb_revision@omg.org Subject: Re: New TypeCode comparison proposal On Wed, 1 Jul 1998, Javier Lopez-Martin wrote: > I agree with this mecanism for stripping outermost aliases. > > However, regarding the stricter inner comparison, remember that any > time > an inner typecode is compared (the only such case is where at least > one > repository id is missing from a complex typecode), they are compared > using > equivalent(), and therefore this whole algorithm is applied, > stripping > inner aliases before attempting inner typecode comparisons. > I don't think this was what you intended, but this is what is in the > proposal > (and I think is the right thing to do). Oops, you are right. Because of the recursive nature, the aliases will be stripped at all levels, not just the outermost. I said this basically to point out that stripping inner aliases will in practice have no effect on the outcome of the comparison, so you might as well not bother. I agree there is no problem with this. However, the spec should still say what "stripping of aliases" means, otherwise there might be confusion. > > Basically, we are suggesting that if both type codes have names, then > > the names should be compared. Again, the reasoning is that if the names > > are different, by definition, the type codes cannot denote the same IDL > > type (otherwise members would have the same name). > > > > If either or both typecodes don't have names, then the comparison is > > true for those names. To illustrate, the following holds for names: > > > > "ABC" == "ABC" > > "ABC" != "DEF" > > "" == "ABC" > > "ABC" == "" > > "" == "" > I cannot agree with this at all, given the "locality" that is intended to > names. I know, I also think it does not make sense to translate an > operation name to a different language to the one used when it was defined, > but this is what the IR chapter says. And I don't see any reason why we > should restrict this. The relevant section of the spec follows (extracted > from CORBA 2.2, page 8-38, section on Typecodes in the IR chapter): > > [ ... ] > > The important thing here is "Since names are local to a Repository, the > name returned from a TypeCode may not match the name ...". > With the above interpretation, names cannot be used for a safe comparison > on type equivalence. They must be compared by equal(), because the > semantics of equal() are different from equivalent(). Well, let's step back for a moment. The issue you describe can arise only if there are two different IRs that store the same type code. Now either these IRs do preserve names or they don't (one may preserve them and the other may not, that's fine). However, *if* the two type codes in the two IRs are indeed the same type code for the same IDL definition, then what we suggested above makes sense: - If both IRs store the names, the names will compare equal as they should. - If either or both repositories throw the names away, then the names are ignored for comparison as they should. What you are alluding to, as far as I can see, can never happen. Either the two type codes are for the same IDL definition, in which case they have the same member names, or they are not. If they *are* from the same IDL definition, for your scenario to arise, an IR would have to (more or less randomly) *replace* the name of, say, a structure member with a different name. I do not believe that spec implies that this is legal behavior for an IR. If it does store a type code for an IDL construct, then that type code either faithfully reproduces the IDL names, or it throws them away. But I don't think it can change them to something else. If what I said above is right, I still believe the name comparison algorithm we suggest would improve type equivalence. Or is there simply something I'm not seeing? 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 Return-Path: Date: Wed, 1 Jul 1998 20:33:08 -0600 From: Javier Lopez-Martin To: javier@cnd.hp.com, michi@dstc.edu.au Subject: Re: New TypeCode comparison proposal Cc: jon@floorboard.com, orb_revision@omg.org, kukura@iona.com Content-Md5: zSv0ycEVk6cOdVxuQ1cjng== > > > Basically, we are suggesting that if both type codes have names, then > > > the names should be compared. Again, the reasoning is that if the names > > > are different, by definition, the type codes cannot denote the same IDL > > > type (otherwise members would have the same name). > > > > > > If either or both typecodes don't have names, then the comparison is > > > true for those names. To illustrate, the following holds for names: > > > > > > "ABC" == "ABC" > > > "ABC" != "DEF" > > > "" == "ABC" > > > "ABC" == "" > > > "" == "" > > > I cannot agree with this at all, given the "locality" that is intended to > > names. I know, I also think it does not make sense to translate an > > operation name to a different language to the one used when it was defined, > > but this is what the IR chapter says. And I don't see any reason why we > > should restrict this. The relevant section of the spec follows (extracted > > from CORBA 2.2, page 8-38, section on Typecodes in the IR chapter): > > > > [ ... ] > > > > The important thing here is "Since names are local to a Repository, the > > name returned from a TypeCode may not match the name ...". > > With the above interpretation, names cannot be used for a safe comparison > > on type equivalence. They must be compared by equal(), because the > > semantics of equal() are different from equivalent(). > > Well, let's step back for a moment. The issue you describe can arise only > if there are two different IRs that store the same type code. Now either > these IRs do preserve names or they don't (one may preserve them and > the other may not, that's fine). However, *if* the two type codes in the > two IRs are indeed the same type code for the same IDL definition, then > what we suggested above makes sense: > > - If both IRs store the names, the names will compare equal as > they should. > > - If either or both repositories throw the names away, then > the names are ignored for comparison as they should. > > What you are alluding to, as far as I can see, can never happen. > > Either the two type codes are for the same IDL definition, > in which case they have the same member names, or they are not. If they *are* > from the same IDL definition, for your scenario to arise, an IR would have > to (more or less randomly) *replace* the name of, say, a structure member > with a different name. I do not believe that spec implies that this is > legal behavior for an IR. If it does store a type code for an IDL construct, > then that type code either faithfully reproduces the IDL names, or it > throws them away. But I don't think it can change them to something else. > > If what I said above is right, I still believe the name comparison algorithm > we suggest would improve type equivalence. > > Or is there simply something I'm not seeing? I'll quote here a very enlightening email segment written some time back (May 1st to be exact) by Bob Kukura: " The current specifications of IDL and the IFR provide no guarantees that the names will be the same in two TypeCodes that identify the "same" type. The IFR interfaces and IDL pragmas allow scoped names to change without effecting the identity of the type. For example, the CORBA::Contained::move() operation changes the scoped name but not the RepositoryId. IDL pragmas can make definitions in different modules have the same RepositoryId. I've always thought of the RepositoryId as the canonical global identifier for types, and the names just a local convenience for human readability. So I agree that names are not significant when deciding whether two TypeCodes identify the same type. But, as I said earlier, I strongly oppose changing the semantics of TypeCode::equal(). The current semantics are well defined and are useful in determining whether there are any visible differences between two TypeCodes. Other operations can be added to provide different forms of comparison. " So, I think you are missing something: the RepositoryIds are the unique identifiers for types, while the names (scoped or not) are not supposed to be identifying except in the context of one specific Repository. Two repositories might have a different view of the *same* type (ie, different names and/or scopes), but the RepositoryId would still indicate equivalence. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: To: Javier Lopez-Martin cc: michi@dstc.edu.au, jon@floorboard.com, orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal Date: Thu, 02 Jul 1998 15:48:48 +1000 From: Keith Duddy Hi all, >> Or is there simply something I'm not seeing? > >I'll quote here a very enlightening email segment written some time back >(May 1st to be exact) by Bob Kukura: > >" >The current specifications of IDL and the IFR provide no guarantees that >the names will be the same in two TypeCodes that identify the "same" >type. The IFR interfaces and IDL pragmas allow scoped names to change >without effecting the identity of the type. For example, the >CORBA::Contained::move() operation changes the scoped name but not the >RepositoryId. IDL pragmas can make definitions in different modules >have the same RepositoryId. Thus - a preprocessor hacker can break the type system and cause an IFR to violate its premise that a RepositoryId is a globally unique identifier for a type (and thus should return a single pointer to a container in the IFR). I think also that the use of move() is also highly problematic (including its use of versioning) and should not be a consideration in this discussion. >I've always thought of the RepositoryId as >the canonical global identifier for types, and the names just a local >convenience for human readability. > >So I agree that names are not significant when deciding whether two >TypeCodes identify the same type. But, as I said earlier, I strongly >oppose changing the semantics of TypeCode::equal(). The current >semantics are well defined and are useful in determining whether there >are any visible differences between two TypeCodes. Other operations can >be added to provide different forms of comparison. >" > >So, I think you are missing something: the RepositoryIds are the unique >identifiers for types, while the names (scoped or not) are not supposed >to be identifying except in the context of one specific Repository. >Two repositories might have a different view of the *same* type (ie, >different names and/or scopes), but the RepositoryId would still >indicate equivalence. Let's look at some premises of the IFR: Section 81. says The Interface Repository provides for the storage, distribution, and management of a collection of related objects' interface definitions. and it states that this information should be able to be used to * Manage the installation and distribution of interface definitions. * Provide components of a CASE environment (for example, an interface browser). * Provide interface information to language bindings (such as a compiler). If this is the case - then all names _must_ be stored, otherwise it would be impossible for a compiler to correctly generate a language mapping. In general the implication is that the OMG IDL that is the source for the definitions stored in the IFR must be preserved without loss of information. Changing or omitting any names of types or their members would defeat this purpose. I recognise that elsewhere in the IFR spec names are not used to identify types. I would like to see the IFR spec fixed in this case. In my view the storage of member names of structured types in the IFR should be mandatory, even if the typecodes returned to identify them omit those names. Then we get onto TypeCodes - these are stored in the IFR, and may also exist independently of it. The ability to leave names out of TypeCodes is merely an efficiency consideration, and (tell me if I'm wrong) no-one ever intended two structurally equivalent types to compare equal if they were defined by different IDL. The current definition of TypeCode::equal() implies as much - it says that unless all operations of two TypeCodes (including those returning names) produce equal results, the Typecodes are not equal. What you are currently proposing is essentially that we weaken this definition (1) to allow aliases to compare equal and that language mappings provide an appropriate means of checking alias differences. (2) that the results of name operations be ignored - even if they return different non-zero length strings. In my view (2) weakens the type system without any corresponding gain in efficiency or usability. K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 2 Jul 1998 16:28:44 +1000 (EST) From: Michi Henning To: Keith Duddy cc: Javier Lopez-Martin , jon@floorboard.com, orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal On Thu, 2 Jul 1998, Keith Duddy wrote: > I recognise that elsewhere in the IFR spec names are not used to > identify types. I would like to see the IFR spec fixed in this > case. > In my view the storage of member names of structured types in the > IFR > should be mandatory, even if the typecodes returned to identify them > omit those names. I agree with Keith here. It seems to me that the root problem is really with the overly permissive definition of the IFR. I see no reason to fiddle with member names of structured types myself. > Then we get onto TypeCodes - these are stored in the IFR, and may also > exist independently of it. The ability to leave names out of TypeCodes > is merely an efficiency consideration, and (tell me if I'm wrong) > no-one ever intended two structurally equivalent types to compare > equal if they were defined by different IDL. This seems to be the crucial point to me as well. Why on earth should there ever be a need for two structures to compare as equal types when the member names are different? I just can't see any use for this... 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 Return-Path: Date: Thu, 02 Jul 1998 11:35:40 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Michi Henning CC: Keith Duddy , Javier Lopez-Martin , orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal References: My turn to chime in here... :-) My guess is that the wording in the IFR spec that suggests that names are not used to identify types was a misguided attempt at allowing for localization of IDL source while still allowing interoperability. Since you can't localize the operation names and still have interoperability, this didn't work. However, I think you guys are arguing about a corner case that isn't really all that significant. What would have to happen for one of these "false-positive" matches to occur? First, the TypeCode must not have a repository id. Hopefully that eliminates 90%+ of the cases, and certainly more over time as ORBs conform to CORBA 2.3. Second, we would have to have two IDL types defined that are structurally equivalent by member types, and then have both of them be used in an any where they can be confused with each other. We would also need for this to happen in an ORB environment that does not put repository ids in TypeCodes, but does put in the name and member_name fields. Altogether, this just doesn't sound very likely. But what happens in this case? The worst that happens is that we confuse one type for the other is that we convert a value of one type into a value of another type. Since they are structurally identical, this shouldn't give the ORB itself any heartburn (crashes or memory leaks). It just seems to me like you are adding work for the equivalence function to catch the 1% case that should become non-existent over time. Michi Henning wrote: > On Thu, 2 Jul 1998, Keith Duddy wrote: > > > I recognise that elsewhere in the IFR spec names are not used to > > identify types. I would like to see the IFR spec fixed in this case. > > In my view the storage of member names of structured types in the IFR > > should be mandatory, even if the typecodes returned to identify them > > omit those names. > > I agree with Keith here. It seems to me that the root problem is really > with the overly permissive definition of the IFR. I see no reason > to fiddle with member names of structured types myself. > > > Then we get onto TypeCodes - these are stored in the IFR, and may also > > exist independently of it. The ability to leave names out of TypeCodes > > is merely an efficiency consideration, and (tell me if I'm wrong) > > no-one ever intended two structurally equivalent types to compare > > equal if they were defined by different IDL. > > This seems to be the crucial point to me as well. Why on earth should there > ever be a need for two structures to compare as equal types when the > member names are different? I just can't see any use for this... > > 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 -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 3 Jul 1998 10:27:53 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Keith Duddy , Javier Lopez-Martin , orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal On Thu, 2 Jul 1998, Jonathan Biggar wrote: > However, I think you guys are arguing about a corner case that isn't really all > that significant. What would have to happen for one of these "false-positive" > matches to occur? First, the TypeCode must not have a repository id. Hopefully > that eliminates 90%+ of the cases, and certainly more over time as ORBs conform to > CORBA 2.3. Second, we would have to have two IDL types defined that are > structurally equivalent by member types, and then have both of them be used in an > any where they can be confused with each other. We would also need for this to > happen in an ORB environment that does not put repository ids in TypeCodes, but > does put in the name and member_name fields. Altogether, this just doesn't sound > very likely. You are putting a strong argument there -- there aren't many cases where it is significant. > It just seems to me like you are adding work for the equivalence function to catch > the 1% case that should become non-existent over time. Well, how much work? With what we suggest, the name comparison function would be: bool equal_names(const char *n1, const char *n2) { if (*n1 == '\0' || *n2 == '\0') return true; return !strcmp(n1, n2); } Not exactly a lot of work to insert one if-statement. I agree that the name comparison we suggest isn't a major improvement. But given that it is absolutely trivial to implement and adds essentially zero run-time overhead, I don't think it would do any harm, so we might as well do it? 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 Return-Path: Date: Fri, 03 Jul 1998 09:47:09 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Michi Henning CC: Keith Duddy , Javier Lopez-Martin , orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal References: I agree, it's not too much work to compare the names, but we still have the statement in the IFR spec that names are not significant. I'm not trying to be stuck on tradition, but are we sure that throwing that away is the right thing to do? Michi Henning wrote: > On Thu, 2 Jul 1998, Jonathan Biggar wrote: > > > However, I think you guys are arguing about a corner case that isn't really all > > that significant. What would have to happen for one of these "false-positive" > > matches to occur? First, the TypeCode must not have a repository id. Hopefully > > that eliminates 90%+ of the cases, and certainly more over time as ORBs conform to > > CORBA 2.3. Second, we would have to have two IDL types defined that are > > structurally equivalent by member types, and then have both of them be used in an > > any where they can be confused with each other. We would also need for this to > > happen in an ORB environment that does not put repository ids in TypeCodes, but > > does put in the name and member_name fields. Altogether, this just doesn't sound > > very likely. > > You are putting a strong argument there -- there aren't many cases where > it is significant. > > > It just seems to me like you are adding work for the equivalence function to catch > > the 1% case that should become non-existent over time. > > Well, how much work? With what we suggest, the name comparison function > would be: > > bool equal_names(const char *n1, const char *n2) > { > if (*n1 == '\0' || *n2 == '\0') > return true; > return !strcmp(n1, n2); > } > > Not exactly a lot of work to insert one if-statement. > > I agree that the name comparison we suggest isn't a major improvement. > But given that it is absolutely trivial to implement and adds essentially > zero run-time overhead, I don't think it would do any harm, so we might > as well do it? > > 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 -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sat, 4 Jul 1998 09:41:55 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Keith Duddy , Javier Lopez-Martin , orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal On Fri, 3 Jul 1998, Jonathan Biggar wrote: > I agree, it's not too much work to compare the names, but we still have the statement in > the IFR spec that names are not significant. I'm not trying to be stuck on tradition, > but are we sure that throwing that away is the right thing to do? I am not sure whether tightening up the IFR wording wouldn't be better. I simply cannot see any legitimate reason for why the IFR would more or less randomly change member names when I populate the IFR. As someone else pointed out, it certainly can't do this for operation names, because otherwise, I could no longer use an IFR to drive a DII invocation. So, why would an IFR change member names (other than to set them to the empty string)? I think it would be better to clarify the wording for the IFR and to leave name comparison as we suggested. That way, type code equivalence gets a more reliable definition. I think it would also make the spec easier to understand. Right now, I have to embark on a major research project before I can even begin to fathom why equivalent as suggested by you and Javier appears to ignore perfectly good information during comparisons. 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 Return-Path: Date: Sat, 04 Jul 1998 11:23:50 -0400 From: Jonathan Biggar Organization: Floorboard Software To: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <359CE0DD.C7E9F393@floorboard.com> Ok, there seems to be a significant faction that thinks that the TypeCode equivalent() operation should also compare names and member names for equality if and only if the type does not have a repository id. So, with Jishnu's permission (or without it :-) I'd like to call for a straw poll to see what the RTF's position is on this. Once I get the results of the poll, I'll repost the proposal taking this and all other comments into account. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 6 Jul 1998 10:16:58 +1000 (EST) From: Michi Henning To: orb_revision@omg.org Subject: TypeCode::equal() Jon suggested: > 9. The TypeCode::equal() operation is not used internally by the ORB > and is deprecated. And Javier said: > And its behaviour remains absolutely unchanged: it performs an exact match, > including names, member_names and the like. Javier is right -- equal performs an exact match (as much as possible). If member names are missing, equal performs structural comparison. If member names differ, equal says "Not Equal". However, I don't think we cannot deprecate the operation as Jon suggested. Rationale: I just played with a function that recursively prints the contents of a type code. Without TypeCode::equal(), I cannot write such a function without getting trapped by recursive type codes. The relevant code snippet for structure type codes is shown below. The point it that to prevent infinite recursion of the function for recursive structures, I need a type code equality operation that does *not* throw away aliases: list tlist; void show_TC(CORBA::TypeCode_ptr tcp) { switch (tcp->kind()) { case CORBA::tk_struct: case CORBA::tk_except: { // // Avoid a recursive loop by checking whether we // have shown this type code before. // list::iterator where; for (where = tlist.begin(); where != tlist.end(); where++) { if (tcp->equal(*where)) break; } // // If we have not seen this type code before, add it // to the list of type codes processed so far and // decode the member type codes. // if (where == tlist.end()) { tlist.push_back(CORBA::TypeCode::_duplicate(tcp)); for (int i = 0; i < tcp->member_count(); i++) { CORBA::String_var mn = tcp->member_name(i); CORBA::TypeCode_var mt = tcp->member_type(i); indent(indent_lvl + 1); cout << mn << ":" << endl; show_TC(mt, tlist, indent_lvl + 2); // Recurse } } } break; } // Deal with other TCKind values here... } I don't think it is possible to write this function without TypeCode::equal (at least not without having to reimplement the semantics of TypeCode::equal). In particular, I cannot use Object::is_equivalent to test if two type codes are the same because TypeCode is a pseudo object that does not inherit from CORBA::Object. So, I think we need to retain TypeCode::equal() and *not* deprecate it -- it is still useful. Cheers, Michi. Return-Path: To: Jonathan Biggar cc: Michi Henning , Javier Lopez-Martin , orb_revision@omg.org, kukura@iona.com Subject: Re: New TypeCode comparison proposal Date: Mon, 06 Jul 1998 11:50:52 +1000 From: Keith Duddy Hi again Jon, >I agree, it's not too much work to compare the names, but we still have the s tatement in >the IFR spec that names are not significant. I'm not trying to be stuck on t radition, >but are we sure that throwing that away is the right thing to do? I probably put too much stuff in my last email. But the point I was trying to get accross was: If the IFR is meant to be a source of type info for stub compilers & dynamic invocations alike (and be an online reference for use instead of a text IDL file) then surely all names are significant. I haven't come accross any ORB to date that does not preserve all names in the IFR (although most don't put them in typecodes - as an efficiency measure). Unless there is some vendor out there who needs to mangle names "locally" for some good reason, then I think the text you & Bob refer to has outlived its potential usefulness, and can be tightened up. Given that this RTF is supposed to allow members to choose to protect specification semantics they rely on, and that no-one has come forward with an argument that they need to change names in the IFR, I think it's appropriate for the RTF to tighten/clarify the spec to make it consistent with its goals as I quoted them in the last email. regards, K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: Sender: jis@fpk.hp.com Date: Mon, 06 Jul 1998 11:36:53 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jonathan Biggar Cc: orb_revision@omg.org, Javier Lopez-Martin Subject: Re: New TypeCode comparison proposal References: <359CE0DD.C7E9F393@floorboard.com> <359E4906.EB52E25E@floorboard.com> Jonathan Biggar wrote: > Ok, there seems to be a significant faction that thinks that the TypeCode equivalent() > operation should also compare names and member names for equality if and only if the type > does not have a repository id. > > So, with Jishnu's permission (or without it :-) I'd like to call for a straw poll to see > what the RTF's position is on this. Once I get the results of the poll, I'll repost the > proposal taking this and all other comments into account. Jon, Of course you have my permission. Since Javier is the one who has participated most in this discussion Javier will cast HP's vote on this one. Thanks, Jishnu. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 6 Jul 1998 10:16:58 +1000 (EST) From: Michi Henning To: orb_revision@omg.org Subject: TypeCode::equal() Jon suggested: > 9. The TypeCode::equal() operation is not used internally by the ORB > and is deprecated. And Javier said: > And its behaviour remains absolutely unchanged: it performs an exact match, > including names, member_names and the like. Javier is right -- equal performs an exact match (as much as possible). If member names are missing, equal performs structural comparison. If member names differ, equal says "Not Equal". However, I don't think we cannot deprecate the operation as Jon suggested. Rationale: I just played with a function that recursively prints the contents of a type code. Without TypeCode::equal(), I cannot write such a function without getting trapped by recursive type codes. The relevant code snippet for structure type codes is shown below. The point it that to prevent infinite recursion of the function for recursive structures, I need a type code equality operation that does *not* throw away aliases: list tlist; void show_TC(CORBA::TypeCode_ptr tcp) { switch (tcp->kind()) { case CORBA::tk_struct: case CORBA::tk_except: { // // Avoid a recursive loop by checking whether we // have shown this type code before. // list::iterator where; for (where = tlist.begin(); where != tlist.end(); where++) { if (tcp->equal(*where)) break; } // // If we have not seen this type code before, add it // to the list of type codes processed so far and // decode the member type codes. // if (where == tlist.end()) { tlist.push_back(CORBA::TypeCode::_duplicate(tcp)); for (int i = 0; i < tcp->member_count(); i++) { CORBA::String_var mn = tcp->member_name(i); CORBA::TypeCode_var mt = tcp->member_type(i); indent(indent_lvl + 1); cout << mn << ":" << endl; show_TC(mt, tlist, indent_lvl + 2); // Recurse } } } break; } // Deal with other TCKind values here... } I don't think it is possible to write this function without TypeCode::equal (at least not without having to reimplement the semantics of TypeCode::equal). In particular, I cannot use Object::is_equivalent to test if two type codes are the same because TypeCode is a pseudo object that does not inherit from CORBA::Object. So, I think we need to retain TypeCode::equal() and *not* deprecate it -- it is still useful. Cheers, Michi. Return-Path: X-Sender: genillou@dimail.epfl.ch References: <359CE0DD.C7E9F393@floorboard.com> Date: Tue, 7 Jul 1998 11:50:53 +0200 To: Michi Henning , Jonathan Biggar From: Guy Genilloud Subject: Re: New TypeCode comparison proposal Cc: Keith Duddy , Javier Lopez-Martin , orb_revision@omg.org, kukura@iona.com, Joaquin Miller At 9:41 AM +1000 7/4/98, Michi Henning wrote: > >I am not sure whether tightening up the IFR wording wouldn't be better. >I simply cannot see any legitimate reason for why the IFR would more or less >randomly change member names when I populate the IFR. As someone else pointed >out, it certainly can't do this for operation names, because otherwise, I >could no longer use an IFR to drive a DII invocation. So, why would an >IFR change member names (other than to set them to the empty string)? Michi and others, I am following your type code discussion out of curiosity, even though I am not an expert in the topic of CORBA type codes (however, I do have a side interest in type checking). I got an idea that I would like you to consider, even though if I am not sure of the implications... Please excuse me if I am besides the point. I also thought about operation names. In fact, for uniformity, it can be interesting to consider a model with just objects, and no data. In that case, data can be considered as immutable objects, with "member names" as operation names (invoked for getting interesting information). Now, it is clear (?) that whilst the name of the class is NOT important for typing, the names of the operations ARE. Going back to data, this would mean that data type names are not important, but member names are... In summary, you may want to require equality of member names, while ignoring the type names themselves. Why? -- Because type names correspond to class/interface names (a class can have several names), whilst parameter member names correspond to operation names. As I said, I am not sure of the implications of what I just wrote. I am thinking loud here -- I did not making a serious study of the problem, which ideally would be required... Best regards Guy Genilloud -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: Date: Mon, 06 Jul 1998 11:11:28 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Michi Henning CC: orb_revision@omg.org Subject: Re: TypeCode::equal() References: Yes, you are right, equal() is the only current (although extremely heavyweight) way to detect recursion. I don't have any problem removing the deprecation language from the proposal. As an aside, I wish TypeCode and Request (at least) supported operations that would make it possible to define sorted or hash tables so that applications can more easily associate application specific information with a TypeCode or Request po. Michi Henning wrote: > Jon suggested: > > > 9. The TypeCode::equal() operation is not used internally by the ORB > > and is deprecated. > > And Javier said: > > > And its behaviour remains absolutely unchanged: it performs an exact match, > > including names, member_names and the like. > > Javier is right -- equal performs an exact match (as much as possible). If > member names are missing, equal performs structural comparison. If member > names differ, equal says "Not Equal". > > However, I don't think we cannot deprecate the operation as Jon suggested. > > Rationale: I just played with a function that recursively prints the > contents of a type code. Without TypeCode::equal(), I cannot write such > a function without getting trapped by recursive type codes. The relevant > code snippet for structure type codes is shown below. The point it that > to prevent infinite recursion of the function for recursive structures, > I need a type code equality operation that does *not* throw away aliases: > > list tlist; > > void > show_TC(CORBA::TypeCode_ptr tcp) > { > switch (tcp->kind()) { > case CORBA::tk_struct: > case CORBA::tk_except: > { > // > // Avoid a recursive loop by checking whether we > // have shown this type code before. > // > list::iterator where; > for (where = tlist.begin(); where != tlist.end(); where++) { > if (tcp->equal(*where)) > break; > } > > // > // If we have not seen this type code before, add it > // to the list of type codes processed so far and > // decode the member type codes. > // > if (where == tlist.end()) { > tlist.push_back(CORBA::TypeCode::_duplicate(tcp)); > for (int i = 0; i < tcp->member_count(); i++) { > CORBA::String_var mn = tcp->member_name(i); > CORBA::TypeCode_var mt = tcp->member_type(i); > indent(indent_lvl + 1); > cout << mn << ":" << endl; > show_TC(mt, tlist, indent_lvl + 2); // Recurse > } > } > } > break; > } > // Deal with other TCKind values here... > } > > I don't think it is possible to write this function without TypeCode::equal > (at least not without having to reimplement the semantics of TypeCode::equal). > > In particular, I cannot use Object::is_equivalent to test if two type codes > are the same because TypeCode is a pseudo object that does not inherit > from CORBA::Object. > > So, I think we need to retain TypeCode::equal() and *not* deprecate it -- > it is still useful. > > Cheers, > > Michi. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 8 Jul 1998 10:10:29 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: TypeCode::equal() On Mon, 6 Jul 1998, Jonathan Biggar wrote: > Yes, you are right, equal() is the only current (although extremely heavyweight) > way to detect recursion. I don't have any problem removing the deprecation > language from the proposal. > > As an aside, I wish TypeCode and Request (at least) supported operations that > would make it possible to define sorted or hash tables so that applications can > more easily associate application specific information with a TypeCode or Request > po. I agreee. In particular, this would be useful for sending multiple deferred requests with the DII, because otherwise, it is difficult to associate the replies with the requests. I'm not sure whether it is really necessary for type codes, because type code equality is really only necessary to detect recursion (I think), and for that, you will never have a large number of type codes to compare. But I wouldn't object to allowing something like a hash() operation for both. 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 Return-Path: Sender: jon@floorboard.com Date: Fri, 10 Jul 1998 13:12:18 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Reissued Proposal for 665, incorporating comments received Ok, here is the revised TypeCode equivalence proposal. Here is a rundown of the changes I made: A. Changed the text that states that names and member_names are local to a Repository to instead state that they may be empty strings, but if not, must be the same identifier as the original IDL source. B. Replaced my equivalent algorithm with the one proposed by Javier. C. Changed the equivalent algorithm to compare non-empty name and member_names for equality. D. Beefed up the concept of TypeCode alias stripping. E. States that the TypeCode returned by DynAny::type() once set (by constructing the DynAny) never changes. F. Removed the statement that TypeCode::equal is deprecated. G. Added Respository::get_canonical_typecode and defined TypeCode::get_canonical_typecode to call it if the ORB can't determine the canonical TypeCode by other means. I think this addresses everyone's concerns. Points 1 through 9 need to be considered as one unit. Point 10 can be voted on independently, but does provide a useful capability for controlling the size and content of TypeCodes. ---------------------------------------------------------------------------- Proposal: 1. Make RepositoryIds mandatory for all TypeCodes that have them. [This was done by the previous core RTF. I am just reiterating it here for completeness.] 2. All TypeCode constants generated by the IDL compiler, as well as all TypeCodes returned by the Interface Repository must include alias TypeCodes wherever a typedef declaration appears in the original IDL source. 3. Each IDL programming language mapping must provide a mechanism for the programmer to ensure that values of the IDL any type contain the exact typecode desired by the programmer. 4. Remove the two sentences in the TypeCode section (8.7.1) that state that name and member name are local to the Interface Repository, and replace them with: The name and member_name fields may be empty strings to reduce the size of a TypeCode. If they are not empty, they must be the same identifier from the IDL source that defines the type. 5. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics: a) If either TypeCode has the kind tk_alias, equivalent recursively calls equivalent with the member TypeCode of the alias and returns that result. b) If the kinds of the two typecodes differ, equivalent returns false. c) If the kinds are equal, and the typecodes have an empty parameter list, equivalent returns true. d) If the typecodes have a simple parameter list, equivalent returns true if the parameter lists of both typecodes are equal, false otherwise. e) If the typecodes have a complex parameter list, equivalent returns true if the RepositoryIds of both typecodes are equal, false if they are different. In case at least one of the typecodes with a complex parameter list has an empty (or no) RepositoryId, then the result of equivalent() is the same as performing an structural comparison, defined as follows: - name and member names are compared if both have non-empty values. If either is an empty string, they are considered equivalent. - simple type parameters are compared for equality (length, count etc) - Typecode parameters are compared by recursively calling equivalent. 6. The ORB uses TypeCode::equivalent for all internal TypeCode comparisons, such as for supporting any (and thus DII and DSI) and DynAny. 7. If the programmer needs to distinguish between a type and/or different aliases of that type, he can call TypeCode::id() and compare the RepositoryIds. 8. All DynAny insert & get operations do not consider aliases as significant. The type() operation however, will return the TypeCode with all of the aliases intact, including type() from any DynAny member components. DynAny::assign() and DynAny::from_any compare the internal TypeCode of the DynAny with the TypeCode of its argument using TypeCode::equivalent() and raise Invalid if equivalent() returns false. Otherwise, the DynAny receives the new value but retains its original TypeCode. 9. The TypeCode::equal() operation is not used internally by the ORB but is still available for application use. 10. Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; The get_compact_typecode operation strips out all optional name & member name fields; it leaves all alias typecodes intact. The get_canonical_typecode operation returns a new TypeCode with all of the optional fields filled in with values. It calls the get_canonical_typecode operation of the default Interface Repository for the ORB (the one returned via the resolve_initial_references operation on the ORB pseudo object) if it cannot determine the new TypeCode using local means. If the ORB must consult the Interface Repository, and it is unavailable, or does not contain the information needed, the call raises the INTF_REPOS system exception. Also add the following operation to CORBA::Repository: interface Repository { ... TypeCode get_canonical_typecode(in TypeCode tc); ... }; The get_canonical_typecode operation looks up the TypeCode in the Interface Repository and returns the fully fleshed-out TypeCode including all repository ids, names, and member_names. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sat, 11 Jul 1998 10:52:42 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Reissued Proposal for 665, incorporating comments received On Fri, 10 Jul 1998, Jonathan Biggar wrote: > Points 1 through 9 need to be considered as one unit. Point 10 can be > voted on independently, but does provide a useful capability for > controlling the size and content of TypeCodes. I like all of this. Thanks for making this effort! 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 Return-Path: From: Javier Lopez-Martin Subject: Re: OMG:Reissued Proposal for 665, incorporating comments received To: jon@floorboard.com Date: Sun, 12 Jul 1998 12:16:20 MDT Cc: orb_revision@omg.org Hi Jon, As you very well know, I support this proposal very much. However, I must insist that I do not agree with comparing names/member_names, and that I believe this is plain incorrect according to the current status of the CORBA 2.2 spec (not being changed for 2.3): > A. Changed the text that states that names and member_names are local > to a Repository to instead state that they may be empty strings, but if > not, must be the same identifier as the original IDL source. > > C. Changed the equivalent algorithm to compare non-empty name and > member_names for equality. > 4. Remove the two sentences in the TypeCode section (8.7.1) that state > that name and member name are local to the Interface Repository, and > replace them with: > > The name and member_name fields may be empty strings to reduce the size > of a TypeCode. If they are not empty, they must be the same identifier > from the IDL source that defines the type. I don't question the good or bad of being able to change names, but I do question that if we do this change as proposed (comparing names/member_names) we are introducing another inconsisency between the considerations for typecode equivalence and what is explained in the IR chapter. I would probably be in favour of a change that would take into account BOTH equivalence and IFR, but doing it here is for me an incomplete change, and is introducing a significant change (inmutability of names/member_names) through the "back door" of another one (typecode equivalence). If we go back to not comparing names, I fully support the proposal. If we keep the name comparison, I strongly object to that part, but still support the rest of the proposal. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Sender: jon@floorboard.com Date: Sun, 12 Jul 1998 13:25:06 -0700 From: Jonathan Biggar To: Javier Lopez-Martin CC: orb_revision@omg.org Subject: Re: OMG:Reissued Proposal for 665, incorporating comments received References: <199807121816.AA084037380@ovdm40.cnd.hp.com> Javier Lopez-Martin wrote: > > Hi Jon, > > As you very well know, I support this proposal very much. > > However, I must insist that I do not agree with comparing > names/member_names, > and that I believe this is plain incorrect according to the current > status > of the CORBA 2.2 spec (not being changed for 2.3): > > > A. Changed the text that states that names and member_names are > local > > to a Repository to instead state that they may be empty strings, > but if > > not, must be the same identifier as the original IDL source. > > > > C. Changed the equivalent algorithm to compare non-empty name and > > member_names for equality. > > > 4. Remove the two sentences in the TypeCode section (8.7.1) that > state > > that name and member name are local to the Interface Repository, > and > > replace them with: > > > > The name and member_name fields may be empty strings to reduce the > size > > of a TypeCode. If they are not empty, they must be the same > identifier > > from the IDL source that defines the type. > > I don't question the good or bad of being able to change names, but > I do > question that if we do this change as proposed (comparing > names/member_names) > we are introducing another inconsisency between the considerations > for > typecode equivalence and what is explained in the IR chapter. The factor that changed my mind is the argument (based on the text in Section 8.1) that the Interface Repository can be used to implement the back end of an IDL compiler. If the compiler does not have access to the name and member name fields from the IR in the same form as the IDL source, then there is no possibility of source interoperability. > I would probably be in favour of a change that would take into account > BOTH equivalence and IFR, but doing it here is for me an incomplete change, > and is introducing a significant change (inmutability of names/member_names) > through the "back door" of another one (typecode equivalence). I'm not trying to change anything by the back door. The intention is to change the IR to require that names (if they are defined) be exactly the same as the IDL source. If you find text in the spec I have missed, please let me know, and I'll add it to the proposal. > If we go back to not comparing names, I fully support the proposal. > If we keep the name comparison, I strongly object to that part, but > still support the rest of the proposal. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Javier Lopez-Martin Subject: Re: Reissued Proposal for 665, incorporating comments received To: jon@floorboard.com Date: Sun, 12 Jul 1998 18:51:26 MDT Cc: javier@cnd.hp.com, orb_revision@omg.org > > As you very well know, I support this proposal very much. > > > > However, I must insist that I do not agree with comparing > names/member_names, > > and that I believe this is plain incorrect according to the > current status > > of the CORBA 2.2 spec (not being changed for 2.3): > > > > I don't question the good or bad of being able to change names, > but I do > > question that if we do this change as proposed (comparing > names/member_names) > > we are introducing another inconsisency between the considerations > for > > typecode equivalence and what is explained in the IR chapter. > > The factor that changed my mind is the argument (based on the text > in > Section 8.1) that the Interface Repository can be used to implement > the > back end of an IDL compiler. If the compiler does not have access > to > the name and member name fields from the IR in the same form as the > IDL > source, then there is no possibility of source interoperability. Yes, this is true. But if an IFR does change names/member names/scoped names, then the source code that uses it should had been adjusted accordingly. And what the IDL compiler should do is what is appropriate for the IFR contents, not the original IDL writeup. > > I would probably be in favour of a change that would take into account > > BOTH equivalence and IFR, but doing it here is for me an incomplete change, > > and is introducing a significant change (inmutability of names/member_names) > > through the "back door" of another one (typecode equivalence). > > I'm not trying to change anything by the back door. The intention is to > change the IR to require that names (if they are defined) be exactly the > same as the IDL source. If you find text in the spec I have missed, > please let me know, and I'll add it to the proposal. Sorry if I sounded too rude, it was not my intention. What I tried to say is that this change implies a lot more things that what it seems to. For example, the following paragraph from the IFR chapter should be changed (from CORBA 2.2, page 8-38, section on Typecodes): " The name operation can also be invoked on object reference, structure, union, enumeration, alias, and exception TypeCodes. It returns the simple name identifying the type within its enclosing scope. Since names are local to a Repository, the name returned from a TypeCode may not match the name of the type in any particular Repository, and may even be an empty string. The member_count and member_name operations can be invoked on structure, union, and enumeration TypeCodes. Member_count returns the number of members constituting the type. Member_name returns the simple name of the member identified by index. Since names are local to a Repository, the name returned from a TypeCode may not match the name of the member in any particular Repository, and may even be an empty string. " The above change effectively forces to make name/member_name unchangeable, and therefore a lot of text in the IR, and some IDL as well, should be changed, to be made consistent (the above quote being one of the cases). I think doing all that is required is way too much to do in the last minute, and introducing the name comparison without the rest of changes creates a clear inconsistency in the spec. I would recommend this issue of "name inmutability" to be raised as a new one, and be dealt with in the next round of the RTF. For the time being, names should not be significant in equivalence, to keep consistency with the current IFR spec. As you already pointed out, Jon, this is only going to make a difference is extremely rare cases (for equivalence), so this does not create any problem of backward compatibility. [NOTE: I would most probably be in favour of making names inmutable, but taking the problem as a whole, and performing all appropriate changes consistently] Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 13 Jul 1998 11:06:11 +1000 (EST) From: Michi Henning To: Javier Lopez-Martin cc: jon@floorboard.com, orb_revision@omg.org Subject: Re: Reissued Proposal for 665, incorporating comments received On Sun, 12 Jul 1998, Javier Lopez-Martin wrote: > > The factor that changed my mind is the argument (based on the text in > > Section 8.1) that the Interface Repository can be used to implement the > > back end of an IDL compiler. If the compiler does not have access to > > the name and member name fields from the IR in the same form as the IDL > > source, then there is no possibility of source interoperability. > > Yes, this is true. But if an IFR does change names/member names/scoped > names, then the source code that uses it should had been adjusted accordingly. > And what the IDL compiler should do is what is appropriate for the IFR > contents, not the original IDL writeup. Javier, what I don't understand is *why* would an IFR ever want to change the member names. I simply cannot see a valid justification for this. So, what do we loose by preventing the IFR from doing this? Nothing, as far as I can see. Those IFRs that exist don't change the member names, so we are not breaking any existing implementation. More bluntly, why insist that the IFR can behave in way that no-one wants to behave in anyway? Wouldn't it be better to require the IFR to preserve the names and make everybody's life easier? > The name operation can also be invoked on object reference, structure, > union, enumeration, alias, and exception TypeCodes. It returns the simple > name identifying the type within its enclosing scope. Since names are local > to a Repository, the name returned from a TypeCode may not match the name > of the type in any particular Repository, and may even be an empty string. So, we can just change the text to say that the name may be empty, but may not differ from the IDL source. > The member_count and member_name operations can be invoked on structure, > union, and enumeration TypeCodes. Member_count returns the number of members > constituting the type. Member_name returns the simple name of the member > identified by index. Since names are local to a Repository, the name returned > from a TypeCode may not match the name of the member in any particular > Repository, and may even be an empty string. > " The same change here would fix this too, no? > The above change effectively forces to make name/member_name unchangeable, > and therefore a lot of text in the IR, and some IDL as well, should be > changed, to be made consistent (the above quote being one of the cases). > > I think doing all that is required is way too much to do in the last minute, > and introducing the name comparison without the rest of changes creates > a clear inconsistency in the spec. I think we have an inconsistency already. In one place, the CORBA spec says that an IFR can be used to create requests for the DII and drive dynamic ORBs, for example for interpreted language bindings. However, the lack of guarantee for the member names in the IFR appears to contradict that. Shouldn't we remove the inconsistency that is already there whether we decide that member names end up getting compared or not? > I would recommend this issue of "name inmutability" to be raised as a new > one, and be dealt with in the next round of the RTF. For the time being, > names should not be significant in equivalence, to keep consistency with > the current IFR spec. Once the names are not considered, but equivalent() is published, people would rightfully complain if the semantics of equivalent() were to change later. Let's get it right first time, if we can! > [NOTE: I would most probably be in favour of making names inmutable, > but taking the problem as a whole, and performing all appropriate > changes consistently] OK, so let's do it! 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 Return-Path: Sender: jon@floorboard.com Date: Sun, 12 Jul 1998 18:09:15 -0700 From: Jonathan Biggar To: Javier Lopez-Martin CC: orb_revision@omg.org Subject: Re: Reissued Proposal for 665, incorporating comments received References: <199807130051.AA096371087@ovdm40.cnd.hp.com> Javier Lopez-Martin wrote: > Sorry if I sounded too rude, it was not my intention. What I tried > to say > is that this change implies a lot more things that what it seems to. > For example, the following paragraph from the IFR chapter should be > changed (from CORBA 2.2, page 8-38, section on Typecodes): > > " > The name operation can also be invoked on object reference, > structure, > union, enumeration, alias, and exception TypeCodes. It returns the > simple > name identifying the type within its enclosing scope. Since names > are local > to a Repository, the name returned from a TypeCode may not match the > name > of the type in any particular Repository, and may even be an empty > string. > > The member_count and member_name operations can be invoked on > structure, > union, and enumeration TypeCodes. Member_count returns the number of > members > constituting the type. Member_name returns the simple name of the > member > identified by index. Since names are local to a Repository, the name > returned > from a TypeCode may not match the name of the member in any > particular > Repository, and may even be an empty string. > " > > The above change effectively forces to make name/member_name > unchangeable, > and therefore a lot of text in the IR, and some IDL as well, should > be > changed, to be made consistent (the above quote being one of the > cases). Ah! So there is the pesky text I couldn't find! I didn't want to leave anything in the IR chapter that said anything like that, but my first search didn't locate the text. Consider the sense of those paragraphs changed to say that names and member names must be the same as the IDL source, or empty. > I think doing all that is required is way too much to do in the last minute, > and introducing the name comparison without the rest of changes creates > a clear inconsistency in the spec. > > I would recommend this issue of "name inmutability" to be raised as a new > one, and be dealt with in the next round of the RTF. For the time being, > names should not be significant in equivalence, to keep consistency with > the current IFR spec. As you already pointed out, Jon, this is only > going to make a difference is extremely rare cases (for equivalence), so > this does not create any problem of backward compatibility. > > [NOTE: I would most probably be in favour of making names inmutable, > but taking the problem as a whole, and performing all appropriate > changes consistently] Does that resolve it? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Sun, 12 Jul 1998 22:41:22 -0400 From: Bob Kukura Organization: IONA Technologies To: Michi Henning CC: Javier Lopez-Martin , jon@floorboard.com, orb_revision@omg.org Subject: Re: Reissued Proposal for 665, incorporating comments received References: Michi Henning wrote: > > On Sun, 12 Jul 1998, Javier Lopez-Martin wrote: > > > > The factor that changed my mind is the argument (based on the > text in > > > Section 8.1) that the Interface Repository can be used to > implement the > > > back end of an IDL compiler. If the compiler does not have > access to > > > the name and member name fields from the IR in the same form as > the IDL > > > source, then there is no possibility of source interoperability. > > > > Yes, this is true. But if an IFR does change names/member > names/scoped > > names, then the source code that uses it should had been adjusted > accordingly. > > And what the IDL compiler should do is what is appropriate for the > IFR > > contents, not the original IDL writeup. > > Javier, what I don't understand is *why* would an IFR ever want to > change > the member names. I simply cannot see a valid justification for > this. > So, what do we loose by preventing the IFR from doing this? Nothing, > as > far as I can see. Those IFRs that exist don't change the member > names, > so we are not breaking any existing implementation. I can't speak for Javier here, but I do mostly agree with his view on this issue. I can assure you that the submitters of the CORBA 2.0 Interface Repository specification did not intend to allow IFRs to "spontaneously" change the names of structure members or anything else. The intention was to allow some flexibility for IDL definitions to evolve while still maintaining interoperability on the wire. The IFR should simply store the names from the IDL files loaded into it, but those IDL files/IFRs might not always be exactly the same across a domain of interoperability. As of CORBA 2.2, nothing breaks if someone decides they want to rename a struct member, as long as each party's IDL file, IFR, and application code agree on the name. Similarly, module, interface, and exception names can change, as long as prefix and/or id pragmas are used to ensure that the RepositoryId remains unchanged. I believe that only operation and attribute names cannot change without breaking interoperability. > > More bluntly, why insist that the IFR can behave in way that no-one > wants > to behave in anyway? Wouldn't it be better to require the IFR to > preserve > the names and make everybody's life easier? I think the question should be: how much of an IDL definition should be significant for interoperability? Right now, its just the RepositoryIds and operation and attribute names that matter. > > > The name operation can also be invoked on object reference, > structure, > > union, enumeration, alias, and exception TypeCodes. It returns the > simple > > name identifying the type within its enclosing scope. Since names > are local > > to a Repository, the name returned from a TypeCode may not match > the name > > of the type in any particular Repository, and may even be an empty > string. > > So, we can just change the text to say that the name may be empty, > but > may not differ from the IDL source. > > > The member_count and member_name operations can be invoked on > structure, > > union, and enumeration TypeCodes. Member_count returns the number > of members > > constituting the type. Member_name returns the simple name of the > member > > identified by index. Since names are local to a Repository, the > name returned > > from a TypeCode may not match the name of the member in any > particular > > Repository, and may even be an empty string. > > " > > The same change here would fix this too, no? > > > The above change effectively forces to make name/member_name > unchangeable, > > and therefore a lot of text in the IR, and some IDL as well, > should be > > changed, to be made consistent (the above quote being one of the > cases). > > > > I think doing all that is required is way too much to do in the > last minute, > > and introducing the name comparison without the rest of changes > creates > > a clear inconsistency in the spec. > > I think we have an inconsistency already. In one place, the CORBA > spec > says that an IFR can be used to create requests for the DII and > drive > dynamic ORBs, for example for interpreted language > bindings. However, > the lack of guarantee for the member names in the IFR appears to > contradict > that. Shouldn't we remove the inconsistency that is already there > whether > we decide that member names end up getting compared or not? > > > I would recommend this issue of "name inmutability" to be raised > as a new > > one, and be dealt with in the next round of the RTF. For the time > being, > > names should not be significant in equivalence, to keep > consistency with > > the current IFR spec. > > Once the names are not considered, but equivalent() is published, > people > would rightfully complain if the semantics of equivalent() were to > change > later. Let's get it right first time, if we can! > > > [NOTE: I would most probably be in favour of making names > inmutable, > > but taking the problem as a whole, and performing all appropriate > > changes consistently] > > OK, so let's do it! > > 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 Return-Path: Sender: jon@floorboard.com Date: Sun, 12 Jul 1998 20:10:06 -0700 From: Jonathan Biggar To: Bob Kukura CC: Michi Henning , Javier Lopez-Martin , orb_revision@omg.org Subject: Re: Reissued Proposal for 665, incorporating comments received References: <35A973D2.14B30504@iona.com> Bob Kukura wrote: > I can't speak for Javier here, but I do mostly agree with his view > on > this issue. > > I can assure you that the submitters of the CORBA 2.0 Interface > Repository specification did not intend to allow IFRs to > "spontaneously" > change the names of structure members or anything else. The > intention > was to allow some flexibility for IDL definitions to evolve while > still > maintaining interoperability on the wire. The IFR should simply > store > the names from the IDL files loaded into it, but those IDL > files/IFRs > might not always be exactly the same across a domain of > interoperability. > > As of CORBA 2.2, nothing breaks if someone decides they want to > rename a > struct member, as long as each party's IDL file, IFR, and > application > code agree on the name. Similarly, module, interface, and exception > names can change, as long as prefix and/or id pragmas are used to > ensure > that the RepositoryId remains unchanged. I believe that only > operation > and attribute names cannot change without breaking interoperability. Ok, now I see the validity of the argument on both sides, and I think I am swayed back to Javier & Bob's side. I called for a straw vote last week and got no explicit responses. I hope you all agree that the general problem of TypeCode comparison needs to be fixed, once and for all, so let's not let it run aground on this particular part of the issue. It's pretty straightforward to remove the name comparison part of the equivalence algorithm as well as the textual changes in my proposal about names and member_names. Jishnu, I guess we need a formal vote on this. Can you place my proposal in vote 3 with three possible responses: Yes-compare-names Yes,-but don't compare names No-don't-like-the-proposal-at-all-standing-in-the-way-of-progress-with-my-head-in-the-sand. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 13 Jul 1998 14:27:28 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Javier Lopez-Martin , jon@floorboard.com, orb_revision@omg.org Subject: Re: Reissued Proposal for 665, incorporating comments received On Sun, 12 Jul 1998, Bob Kukura wrote: > I can assure you that the submitters of the CORBA 2.0 Interface > Repository specification did not intend to allow IFRs to > "spontaneously" > change the names of structure members or anything else. The > intention > was to allow some flexibility for IDL definitions to evolve while > still > maintaining interoperability on the wire. The IFR should simply > store > the names from the IDL files loaded into it, but those IDL > files/IFRs > might not always be exactly the same across a domain of > interoperability. OK, I can see the motivation. I still can't see why I would want that. Surely, if I change an IDL definition for a struct, I wouldn't just go an change a member name, but make more substantive changes? I just don't see why this flexibility would ever be needed. > I think the question should be: how much of an IDL definition should be > significant for interoperability? Right now, its just the RepositoryIds > and operation and attribute names that matter. Yes. Of course, you could argue that interoperability can also be destroyed by the possibly different member names. For example, a Notification Service filter may break if all of a sudden it gets a type code from another ORB that has different member names. At any rate, as Jon said, I also don't want to get the type equivalence resolution to get hung up on this. If the majority of people feel that type names must be ignored during type code equivalence testing, I think I will survive ;-) 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 Return-Path: From: Javier Lopez-Martin Subject: Re: Reissued Proposal for 665, incorporating comments received To: jon@floorboard.com Date: Mon, 13 Jul 1998 0:38:03 MDT Cc: javier@cnd.hp.com, orb_revision@omg.org > > Ah! So there is the pesky text I couldn't find! I didn't want to > leave > anything in the IR chapter that said anything like that, but my > first > search didn't locate the text. Consider the sense of those > paragraphs > changed to say that names and member names must be the same as the > IDL > source, or empty. > > > I think doing all that is required is way too much to do in the > last minute, > > and introducing the name comparison without the rest of changes > creates > > a clear inconsistency in the spec. > > > > I would recommend this issue of "name inmutability" to be raised > as a new > > one, and be dealt with in the next round of the RTF. For the time > being, > > names should not be significant in equivalence, to keep > consistency with > > the current IFR spec. As you already pointed out, Jon, this is > only > > going to make a difference is extremely rare cases (for > equivalence), so > > this does not create any problem of backward compatibility. > > > > [NOTE: I would most probably be in favour of making names > inmutable, > > but taking the problem as a whole, and performing all appropriate > > changes consistently] > > Does that resolve it? Actually, I don't know. And that is why I oppose this change to make names significant and inmutable without understanding fully all the implications (both technical and from the spec point of view). Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: From: Javier Lopez-Martin Subject: Re: Reissued Proposal for 665, incorporating comments received To: kukura@iona.com Date: Mon, 13 Jul 1998 0:43:37 MDT Cc: michi@dstc.edu.au, javier@cnd.hp.com, jon@floorboard.com, orb_revision@omg.org Hi Bob, > I can't speak for Javier here, but I do mostly agree with his view on > this issue. Thanks for supporting me, I was starting to feel lonely ;-) You can speak for me any time (if you say the same as I do, of course :-) > I can assure you that the submitters of the CORBA 2.0 Interface > Repository specification did not intend to allow IFRs to > "spontaneously" > change the names of structure members or anything else. The > intention > was to allow some flexibility for IDL definitions to evolve while > still > maintaining interoperability on the wire. The IFR should simply > store > the names from the IDL files loaded into it, but those IDL > files/IFRs > might not always be exactly the same across a domain of > interoperability. > > As of CORBA 2.2, nothing breaks if someone decides they want to > rename a > struct member, as long as each party's IDL file, IFR, and > application > code agree on the name. Similarly, module, interface, and exception > names can change, as long as prefix and/or id pragmas are used to > ensure > that the RepositoryId remains unchanged. I believe that only > operation > and attribute names cannot change without breaking interoperability. > > > > > > More bluntly, why insist that the IFR can behave in way that > no-one wants > > to behave in anyway? Wouldn't it be better to require the IFR to > preserve > > the names and make everybody's life easier? > > I think the question should be: how much of an IDL definition should > be > significant for interoperability? Right now, its just the > RepositoryIds > and operation and attribute names that matter. I think that all these arguments you are giving are just enough reason to NOT change this fact without a better analysis of cost/impact. Therefore, the names should not be changed in significance in the equivalence issue. If this is undesirable for some cases, we should file another issue, and try to solve it under that one, but not for 2.3 (no time). Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Sender: jon@floorboard.com Date: Mon, 13 Jul 1998 11:44:46 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: [Fwd: Reissued Proposal for 665, incorporating comments received] Meant to send this to everyone... -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.orgMessage-ID: <35AA3A6B.811A737F@floorboard.com> Date: Mon, 13 Jul 1998 09:48:43 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Jishnu Mukerji Subject: Re: Reissued Proposal for 665, incorporating comments received References: <35A973D2.14B30504@iona.com> <35A97A8E.E8D277CB@floorboard.com> <35A9F974.CCDEA0F0@fpk.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jishnu Mukerji wrote: > > Jonathan Biggar wrote: > > > Yes-compare-names > > Yes,-but don't compare names > > > > No-don't-like-the-proposal-at-all-standing-in-the-way-of-progress-with-my- > > head-in-the-sand. > > :-) > > OK. Now I've got the possible answers. As soon as you give me a > formal statement of the > question it will be on the vote. Ok, here is the proposal again, with the highlighted sections that apply to the naming issue: A. I have provided two versions of point 4, one if you want name comparison, and one if you don't. B. Step 5e1 is optional depending on the outcome of the name comparison issue. Here is the way people should vote on this: Yes, with name comparison Yes, but no name comparison No, I'm-a-M$-spy-and-I-want-DCOM-to-win :-) Again, Point 10 is a standalone part and can be voted on separately from the rest. ---------------------------------------------------------------------------- Proposal: 1. Make RepositoryIds mandatory for all TypeCodes that have them. [This was done by the previous core RTF. I am just reiterating it here for completeness.] 2. All TypeCode constants generated by the IDL compiler, as well as all TypeCodes returned by the Interface Repository must include alias TypeCodes wherever a typedef declaration appears in the original IDL source. 3. Each IDL programming language mapping must provide a mechanism for the programmer to ensure that values of the IDL any type contain the exact typecode desired by the programmer. [Name comparison version] 4. Remove the two sentences in the TypeCode section (8.7.1) that state that name and member name are local to the Interface Repository, and replace them with: The name and member_name fields may be empty strings to reduce the size of a TypeCode. If they are not empty, they must be the same identifier from the IDL source that defines the type. [Non-name comparison version] 4. Since name and member_name fields are considered local to the Interface Repository, these fields are never considered as significant for TypeCode equivalence comparison. 5. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics: a) If either TypeCode has the kind tk_alias, equivalent recursively calls equivalent with the member TypeCode of the alias and returns that result. b) If the kinds of the two typecodes differ, equivalent returns false. c) If the kinds are equal, and the typecodes have an empty parameter list, equivalent returns true. d) If the typecodes have a simple parameter list, equivalent returns true if the parameter lists of both typecodes are equal, false otherwise. e) If the typecodes have a complex parameter list, equivalent returns true if the RepositoryIds of both typecodes are equal, false if they are different. In case at least one of the typecodes with a complex parameter list has an empty (or no) RepositoryId, then the result of equivalent() is the same as performing an structural comparison, defined as follows: 1. name and member names are compared if both have non-empty values. If either is an empty string, they are considered equivalent. 2. simple type parameters are compared for equality (length, count etc) 3. Typecode parameters are compared by recursively calling equivalent. 6. The ORB uses TypeCode::equivalent for all internal TypeCode comparisons, such as for supporting any (and thus DII and DSI) and DynAny. 7. If the programmer needs to distinguish between a type and/or different aliases of that type, he can call TypeCode::id() and compare the RepositoryIds. 8. All DynAny insert & get operations do not consider aliases as significant. The type() operation however, will return the TypeCode with all of the aliases intact, including type() from any DynAny member components. DynAny::assign() and DynAny::from_any compare the internal TypeCode of the DynAny with the TypeCode of its argument using TypeCode::equivalent() and raise Invalid if equivalent() returns false. Otherwise, the DynAny receives the new value but retains its original TypeCode. 9. The TypeCode::equal() operation is not used internally by the ORB but is still available for application use. 10. Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; The get_compact_typecode operation strips out all optional name & member name fields; it leaves all alias typecodes intact. The get_canonical_typecode operation returns a new TypeCode with all of the optional fields filled in with values. It calls the get_canonical_typecode operation of the default Interface Repository for the ORB (the one returned via the resolve_initial_references operation on the ORB pseudo object) if it cannot determine the new TypeCode using local means. If the ORB must consult the Interface Repository, and it is unavailable, or does not contain the information needed, the call raises the INTF_REPOS system exception. Also add the following operation to CORBA::Repository: interface Repository { ... TypeCode get_canonical_typecode(in TypeCode tc); ... }; The get_canonical_typecode operation looks up the TypeCode in the Interface Repository and returns the fully fleshed-out TypeCode including all repository ids, names, and member_names. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: [Fwd: Reissued Proposal for 665, incorporating comments received] Date: Tue, 14 Jul 1998 12:13:27 +1000 From: Keith Duddy Hi Jon and all, >Ok, here is the proposal again, with the highlighted sections that apply >to the naming issue: > [...] > ... > boolean equivalent(in TypeCode other); > ... >}; > >with the following semantics: > >a) If either TypeCode has the kind tk_alias, equivalent recursively >calls equivalent with the member TypeCode of the alias and returns that >result. I know what this is meant to mean, but i don't know if you've captured it. (Specifically the "recursively" seems to aply to calling equivalent rather than to stripping the aliases.) I think it should say: Both Typecodes should be checked to see if they have the kind tk_alias. If so, each alias should be replaced by its member TypeCode, recursively until the kind is not tk_alias. At this point comparison resumes. In the rest of the description I think the term "parameter" should be replaced by "member", as the PIDL refers to members now - parameters being the pre-CORBA2 terminology. Other than that I think your description is good. regards, K P.S. If you recognise me at Helsinki please intoduce yourself so I can put a face to the name. -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: Sender: jon@floorboard.com Date: Wed, 15 Jul 1998 13:58:51 -0700 From: Jonathan Biggar To: Jishnu Mukerji CC: T E Rutt , Javier Lopez-Martin , orb_revision@omg.org, Michi Henning Subject: Re: Tom Rutt vote on Core vote2 (actually Vote 3) References: <199807151528.LAA29142@holta.ho.lucent.com> <35ACE0B0.C5C10149@fpk.hp.com> Jishnu Mukerji wrote: > > Issue 665: accept non-name comparison for equivalent operation, > but do not accept > > looseness of statement proposed for item 4. Vote for non-name > comparison > > is contingent on adding the following > > sentence after the proposed non-name comparison change in item 4: > > " > > If they are not empty, they must include the same identifier > > as used in the IDL source defining the type for that IR. > > " > > > > I think I could live with that, since I believe that was the intent, > but let me consult my TypeCode expert > Javier. Javier, what do you think? I disagree with the proposed change. The IFR text is clear that names can differ from IFR to IFR, so this change is inconsistent with that text. > > Issue 999: > > The sentence in para 1 from the IR stating "It does not matter > what format is used for any particular > > RepositoryId." Seems to imply that other id formats are allowed > for the repository id. This new change is > > very restrictive.. How can we evolve with such a restrictive > sentence. It is also in conflict with the > > proposed resolution for Issue 444. I don't understand the objection. My reading of that sentence is that it means to say that each IDL construct in an IDL source file has its own RepositoryId, and each construct can have a RepositoryId format specified independently of the other IDL constructs in the same file. > > Issue 444 has the following proposed revision: > > Append the following sentences to Para 1 of section 8.6.4 > > > > "Conforming IDL compilers may support additional non-standard > pragmas, > > but must not refuse to compile IDL source containing non-standard > > pragmas that are not understood by the compiler." > > I think we should let the 444 resolution stand as is, and try to > figure out a consensus on 999, with or > without that restrictive sentence. Voters, any opinions? I don't see how 444 conflicts with 999 at all. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jis@fpk.hp.com Date: Wed, 15 Jul 1998 17:41:34 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jonathan Biggar Cc: Jishnu Mukerji , T E Rutt , Javier Lopez-Martin , orb_revision@omg.org, Michi Henning Subject: Re: Tom Rutt vote on Core vote2 (actually Vote 3) References: <199807151528.LAA29142@holta.ho.lucent.com> <35ACE0B0.C5C10149@fpk.hp.com> <35AD180B.704DC9AE@floorboard.com> Jonathan Biggar wrote: > Jishnu Mukerji wrote: > > > Issue 665: accept non-name comparison for equivalent operation, > but do not accept > > > looseness of statement proposed for item 4. Vote for non-name > comparison > > > is contingent on adding the following > > > sentence after the proposed non-name comparison change in item > 4: > > > " > > > If they are not empty, they must include the same identifier > > > as used in the IDL source defining the type for that IR. > > > " > > > > > > > I think I could live with that, since I believe that was the > intent, but let me consult my TypeCode expert > > Javier. Javier, what do you think? > > I disagree with the proposed change. The IFR text is clear that > names > can differ from IFR to IFR, so this change is inconsistent with that > text. OK, I see where I goofed. So in penance I will not post anything else after this message on the orb_revision list until tomorrow 7/15/98) morning. So no vote 4 today:-) Thanks (Javier and Jon) for all the clarification. Jishnu. Return-Path: Date: Wed, 15 Jul 1998 18:27:31 -0400 From: Bob Kukura Organization: IONA Technologies To: orb_revision@omg.org Subject: orb_revision issue 665 Hi, I support the addition of an operation such as TypeCode::equivalent(), but feel strongly that the current proposal needs a bit of work before I can recommend that Martin vote YES on it. I've discussed these issues with Steve Vinoski, and he concurs. Here are the points I have issues with or comments on: 4) I favor the non-name comparison version. 5) I would much rather see the comparison defined in terms of the TypeCode operations rather than parameters. For one thing, its not clear whether the proposed text is in terms of the CDR encoding parameters or the TypeCode::parameter() operation parameters. Since the later is deprecated (see my previous email), I'll assume the former. If it remains in terms of CDR parameter lists, then we at least need a forward reference to that part of the specification, and probably some text that clarifies that using CDR parameter lists doesn't require or imply that the TypeCodes were necessarily ever encoded in CDR. If others agree that defining equivalent() on terms of CDR encoding parameter is not appropriate, I'd be happy to provide text defining it in terms of public TypeCode operations. 6 and 9) It is okay to say the ORB uses equivalent() for specific TypeCode comparisons, but I don't think we can or should require that this is the only form of comparison used internally or that equal() is not used for anything internally. 10) The TypeCode::get_canonical_typecode() operation should not be included. Because TypeCode literals are available directly from the language mapping, they are not necessarily associated with any ORB instance, and therefore there may be no way to determine what IFR to use to implement this operation. The Repository::get_canonical_typecode() operation doesn't suffer from this problem, and is all that is needed. -Bob Return-Path: Date: Wed, 15 Jul 1998 17:02:21 -0600 From: Javier Lopez-Martin To: orb_revision@omg.org, kukura@iona.com Subject: Re: orb_revision issue 665 Content-Md5: J6kPa5womGct/2KEY9prUg== Hello, > I support the addition of an operation such as TypeCode::equivalent(), > but feel strongly that the current proposal needs a bit of work before I > can recommend that Martin vote YES on it. I've discussed these issues > with Steve Vinoski, and he concurs. > > Here are the points I have issues with or comments on: > > 4) I favor the non-name comparison version. > > 5) I would much rather see the comparison defined in terms of the > TypeCode operations rather than parameters. For one thing, its not > clear whether the proposed text is in terms of the CDR encoding > parameters or the TypeCode::parameter() operation parameters. Since the > later is deprecated (see my previous email), I'll assume the former. If > it remains in terms of CDR parameter lists, then we at least need a > forward reference to that part of the specification, and probably some > text that clarifies that using CDR parameter lists doesn't require or > imply that the TypeCodes were necessarily ever encoded in CDR. If > others agree that defining equivalent() on terms of CDR encoding > parameter is not appropriate, I'd be happy to provide text defining it > in terms of public TypeCode operations. When I wrote the description of the rules, I was thinking of the CDR parameter lists. It seemed to me like a simpler algorithm that the one that Jon had originally written. I didn't notice that the CDR descriptions came after this in the spec. However, if you prefer the algorithm to be based on Typecode API operations, I have no objection (given the semantics are kept as specified). > 6 and 9) It is okay to say the ORB uses equivalent() for specific > TypeCode comparisons, but I don't think we can or should require > that > this is the only form of comparison used internally or that equal() > is > not used for anything internally. I agree that the statement is probably too strong. However, the intent in this phrase (as I understood it, of course; I cannot speak for Jon) is that every time the spec talks about typecode equivalence, or type compatibility, it is implicitly referring to equivalent() and not to equal(). If somewhere the use of equal() is required, it should be explicitly stated that way. Do you agree with this intent? In case you do, could you provide text with this intent but not being too prescriptive? > 10) The TypeCode::get_canonical_typecode() operation should not be > included. Because TypeCode literals are available directly from the > language mapping, they are not necessarily associated with any ORB > instance, and therefore there may be no way to determine what IFR to > use > to implement this operation. The > Repository::get_canonical_typecode() > operation doesn't suffer from this problem, and is all that is > needed. I agree with this one. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Sender: jon@floorboard.com Date: Wed, 15 Jul 1998 17:29:33 -0700 From: Jonathan Biggar To: Bob Kukura CC: orb_revision@omg.org Subject: Re: orb_revision issue 665 References: <35AD2CD3.BEB9BB33@iona.com> Bob Kukura wrote: > > Hi, > > I support the addition of an operation such as > TypeCode::equivalent(), > but feel strongly that the current proposal needs a bit of work > before I > can recommend that Martin vote YES on it. I've discussed these > issues > with Steve Vinoski, and he concurs. > > Here are the points I have issues with or comments on: > > 4) I favor the non-name comparison version. > > 5) I would much rather see the comparison defined in terms of the > TypeCode operations rather than parameters. For one thing, its not > clear whether the proposed text is in terms of the CDR encoding > parameters or the TypeCode::parameter() operation parameters. Since > the > later is deprecated (see my previous email), I'll assume the > former. If > it remains in terms of CDR parameter lists, then we at least need a > forward reference to that part of the specification, and probably > some > text that clarifies that using CDR parameter lists doesn't require > or > imply that the TypeCodes were necessarily ever encoded in CDR. If > others agree that defining equivalent() on terms of CDR encoding > parameter is not appropriate, I'd be happy to provide text defining > it > in terms of public TypeCode operations. That's ok with me. I will work up a new version of the algorithm that uses the TypeCode operations (kind(), id(), name(), member_count(), member_name(), member(), member_label(), discriminator_type(), default_index(), length(), content_type(), digits() and scale()). > 6 and 9) It is okay to say the ORB uses equivalent() for specific > TypeCode comparisons, but I don't think we can or should require > that > this is the only form of comparison used internally or that equal() > is > not used for anything internally. It is important for ORB interoperability that all ORBs compare TypeCodes in the same way. The two places I am sure need this treatment are the handling of any and DynAny, but there may be more. I can see removing the statement about equal() (since there might be a need, like detecting recursion), but we need to be explicit about when equivalent() is usedl. > 10) The TypeCode::get_canonical_typecode() operation should not be > included. Because TypeCode literals are available directly from the > language mapping, they are not necessarily associated with any ORB > instance, and therefore there may be no way to determine what IFR to > use > to implement this operation. The > Repository::get_canonical_typecode() > operation doesn't suffer from this problem, and is all that is > needed. Then why don't we use the same argument and define Object::get_interface() to only return a RepositoryId? The ORB already has a concept of a default Interface Repository for get_interface(), why not use the same for TypeCodes? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 16 Jul 1998 10:52:54 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Bob Kukura , orb_revision@omg.org Subject: Re: orb_revision issue 665 On Wed, 15 Jul 1998, Jonathan Biggar wrote: > > 10) The TypeCode::get_canonical_typecode() operation should not be > > included. Because TypeCode literals are available directly from > the > > language mapping, they are not necessarily associated with any ORB > > instance, and therefore there may be no way to determine what IFR > to use > > to implement this operation. The > Repository::get_canonical_typecode() > > operation doesn't suffer from this problem, and is all that is > needed. > > Then why don't we use the same argument and define > Object::get_interface() to only return a RepositoryId? The ORB > already > has a concept of a default Interface Repository for get_interface(), > why > not use the same for TypeCodes? I don't think returning just a repository ID from get_interface would be sufficient, because the client then would not know *which* repository to go to for the details. Of course, you may argue that a moot point, because an IOR does not include the IOR of its interface repository. However, we may decide to embed interface repository IORs in IORs in the future... 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 Return-Path: Sender: jon@floorboard.com Date: Wed, 15 Jul 1998 18:21:53 -0700 From: Jonathan Biggar To: Michi Henning CC: Bob Kukura , orb_revision@omg.org Subject: Re: orb_revision issue 665 References: Michi Henning wrote: > > On Wed, 15 Jul 1998, Jonathan Biggar wrote: > > > > 10) The TypeCode::get_canonical_typecode() operation should not > be > > > included. Because TypeCode literals are available directly from > the > > > language mapping, they are not necessarily associated with any > ORB > > > instance, and therefore there may be no way to determine what > IFR to use > > > to implement this operation. The > Repository::get_canonical_typecode() > > > operation doesn't suffer from this problem, and is all that is > needed. > > > > Then why don't we use the same argument and define > > Object::get_interface() to only return a RepositoryId? The ORB > already > > has a concept of a default Interface Repository for > get_interface(), why > > not use the same for TypeCodes? > > I don't think returning just a repository ID from get_interface > would be > sufficient, because the client then would not know *which* > repository > to go to for the details. Of course, you may argue that a moot > point, > because an IOR does not include the IOR of its interface repository. > However, we may decide to embed interface repository IORs in IORs > in the future... Nope, you are right here. The returned InterfaceDef does contain an operation that allows you to get the Interface Repository reference. After reconsideration, I don't have a problem with removing TypeCode::get_canonical_typecode from the proposal. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Thu, 16 Jul 1998 21:45:29 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Final version of Issue 665 proposal (prose form) Ok, here is the (hopefully) final version of the proposal: A. The consensus on name comparison is to drop it. B. I have rewritten the equivalence algorithm in terms of the operations defined for the TypeCode pseudo-object. C. I have dropped the old point 9 about the use of TypeCode::equal for internal use by the ORB. D. I have dropped the TypeCode::get_canonical_typecode operation. Again, Point 9 is a standalone part and can be voted on separately from the rest. ---------------------------------------------------------------------------- Proposal: 1. Make RepositoryIds mandatory for all TypeCodes that have them. [This was done by the previous core RTF. I am just reiterating it here for completeness.] 2. All TypeCode constants generated by the IDL compiler, as well as all TypeCodes returned by the Interface Repository must include alias TypeCodes wherever a typedef declaration appears in the original IDL source. 3. Each IDL programming language mapping must provide a mechanism for the programmer to ensure that values of the IDL any type contain the exact typecode desired by the programmer. 4. Since name and member_name fields are considered local to the Interface Repository, these fields are never considered as significant for TypeCode equivalence comparison. 5. Define a new equivalent operation for TypeCodes: pseudo interface TypeCode { ... boolean equivalent(in TypeCode other); ... }; with the following semantics for comparing the two TypeCodes: a) if the result of the kind operation on either TypeCode is tk_alias, recursively replace the TypeCode with the result of calling content_type, until the kind is no longer tk_alias. b) If results of the kind operation on each typecode differ, equivalent returns false. c) If the id operation is valid for the TypeCode kind, equivalent returns true if the results of id for both TypeCodes are non-empty strings and both strings are equal. If either or both id is an empty string, the equivalent will perform a structural comparison of the TypeCodes by comparing the results of the other TypeCode operations in steps d through g. The structural comparison only calls operations that are valid for the given TypeCode kind. If any of these operations do not return equal results, then equivalent returns false. d) The results of the name and member_name operations are ignored and not compared. e) The results of the member_count, discriminator_type, default_index, length, digits and scale operations are compared. f) The results of the member_label operation for each member index of a union TypeCode are compared for equality. Note that this means that unions whose members are not defined in the same order are not considered equivalent. g) The results of the member_type operation for each member index, and the result of the content_type operation are compared by recursively calling equivalent. 6. The ORB uses TypeCode::equivalent for all internal TypeCode comparisons, such as for supporting any (and thus DII and DSI) and DynAny. 7. If the programmer needs to distinguish between a type and/or different aliases of that type, he can call TypeCode::id() and compare the RepositoryIds. 8. All DynAny insert & get operations do not consider aliases as significant. The type() operation however, will return the TypeCode with all of the aliases intact, including type() from any DynAny member components. DynAny::assign() and DynAny::from_any compare the internal TypeCode of the DynAny with the TypeCode of its argument using TypeCode::equivalent() and raise Invalid if equivalent() returns false. Otherwise, the DynAny receives the new value but always retains its original TypeCode. 9. Define a new operation: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); ... }; The get_compact_typecode operation strips out all optional name & member name fields; it leaves all alias typecodes intact. Also add the following operation to CORBA::Repository: interface Repository { ... TypeCode get_canonical_typecode(in TypeCode tc); ... }; The get_canonical_typecode operation looks up the TypeCode in the Interface Repository and returns the full TypeCode including all repository ids, names, and member_names. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 17 Jul 1998 16:03:20 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Final proposal for Issue 665 (edits version) On Thu, 16 Jul 1998, Jonathan Biggar wrote: Thanks for doing this Jon! Major improvement over the previous state of affairs! > I think that covers everything. I'd appreciate it if other RTF members > could look this over and suggest improved wording or identify anything I > have missed. Some minor editorial comments, simply to improve style a little and deal with typos: > Here is the proposal for Issue 665 as a list of edits to CORBA 2.2: > > Replace the first paragraph of 8.7.2 with: > > For IDL type declarations (typedef, struct, union, enum and > interfaces), > the IDL compiler will (if asked) produce a declaration of a TypeCode > constant. See the language mapping rules for more information about > the > names of the generated TypeCode constants. TypeCode constants will ^^^^ > include tk_alias definitions wherever an IDL typedef is referenced. Delete "will", it is redundant. > These constants can be used with the dynamic invocation interface, and > any other routines that require TypeCodes. Delete the command and "any": These constants can be used with the dynamic invocation interface and other routines that require TypeCodes. > In secion 3.8.2 following to the paragraph describing the any type: > > An any logically contains a TypeCode (see 8.7) and a value that is > described by the TypeCode. Each IDL language mapping will provide Say "provides" instead of "will provide". > operations that allow programers to insert and access the TypeCode and > value contained in an any. > > -------------------------------------------------------------------------------- > > Add the following operations to the TypeCode interface definition in > both sections 8.7 and 8.8, right after the equal operation: > > ... > interface TypeCode { > ... > boolean equivlant(in TypeCode tc); Should be "equivalent". > TypeCode get_compact_typecode(); > .... > }; > > > -------------------------------------------------------------------------------- > c) If the id operation is valid for the TypeCode kind, equivalent > returns true if the results of id for both TypeCodes are non-empty > strings and both strings are equal. If either or both id is an > empty > string, the equivalent will perform a structural comparison of the > TypeCodes by comparing the results of the other TypeCode operations > in > steps d through g. The structural comparison only calls operations > that > are valid for the given TypeCode kind. If any of these operations > do > not return equal results, then equivalent returns false. I would delete "The structural comparison only calls operations that are valid for the given TypeCode kind." I think it is redundant because if it called operations that are not valid for a particular kind, the implementation would be buggy. > f) The results of the member_label operation for each member index of a > union TypeCode are compared for equality. Note that this means that > unions whose members are not defined in the same order are not > considered equivalent. We have a change on in the interop RTF up for vote that requires type codes to preserve the order of union members when marshaled. So far, no-one has objected. If that change is accepted, the note about the order of union members can be removed, because all unions of the same type will have the members in the same order in their type codes. > g) The results of the member_type operation for each member index, and > the result of the content_type operation are compared by recursively > calling equivalent. > > If the programmer needs to distinguish between a type and/or different > aliases of that type, he can supplement equivalent by directly invoking ^^ > the id operation and comparing the results. True for the most part, but arguably politically incorrect. I would reword to: Programmers can distinguish betweena tyep and/or different aliases of that type by directly invoking the id operation and comparing the results. > Add the following paragraph to section 8.8, right after the description > of the lookup_id operation: > > The get_canonical_typecode operation looks up the TypeCode in the > Interface Repository and returns the an equivalent TypeCode including ^^^ ^^^^^^^^^ Delete "the". Replace "including" with "that includes", otherwise it is ambiguous. > all repository ids, names, and member_names. If the top level TypeCode > does not contain a RepositoryId, (such as array and sequence TypeCodes, > or TypeCodes from older ORBs), then a new TypeCode is constructed by > recursively calling get_canonical_typecode on each member TypeCode of > the original TypeCode. > > -------------------------------------------------------------------------------- > > Change the last paragraph of the description of the DynAny::assign > operation, section 7.2.3 to: > > If an invalid DynAny object is passed (it has a typecode that is not ^^^^^^ Replace "it has" with "a DynAny with". > equivalent or doesn't contain a meaningful value), the Invalid exception > is returned. > > -------------------------------------------------------------------------------- > > Change the last paragraph of the description of the DynAny::from_any > operation, section 7.2.3 to: > > If an invalid any is passed (it has a typecode that is not equivalent, ^^^^^^ Replace "it has" with "an any with". > or hasn't been assigned a value) the Invalid exception is returned. > > > Add the following paragraph to the description of the > DynAny::current_component operation in section 7.2.3, right after > the > first paragraph: > > The TypeCode of the component DynAny will be the corresponding ^^^^^^^ Replace "will be" with "is". 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 Return-Path: Sender: jon@floorboard.com Date: Thu, 16 Jul 1998 23:11:37 -0700 From: Jonathan Biggar To: Michi Henning CC: orb_revision@omg.org Subject: Re: Final proposal for Issue 665 (edits version) References: Michi Henning wrote: > > On Thu, 16 Jul 1998, Jonathan Biggar wrote: > > Thanks for doing this Jon! Major improvement over the previous state > of affairs! Thanks for the comments. Of course I was foolish to label this the "final" proposal. :-) > > c) If the id operation is valid for the TypeCode kind, equivalent > > returns true if the results of id for both TypeCodes are non-empty > > strings and both strings are equal. If either or both id is an > empty > > string, the equivalent will perform a structural comparison of the > > TypeCodes by comparing the results of the other TypeCode > operations in > > steps d through g. The structural comparison only calls > operations that > > are valid for the given TypeCode kind. If any of these operations > do > > not return equal results, then equivalent returns false. > > I would delete > > "The structural comparison only calls operations that are > valid for the given TypeCode kind." > > I think it is redundant because if it called operations that are not > valid for a particular kind, the implementation would be buggy. It never hurts to be explicit... > > f) The results of the member_label operation for each member index of a > > union TypeCode are compared for equality. Note that this means that > > unions whose members are not defined in the same order are not > > considered equivalent. > > We have a change on in the interop RTF up for vote that requires type codes > to preserve the order of union members when marshaled. So far, no-one > has objected. If that change is accepted, the note about the order of > union members can be removed, because all unions of the same type will > have the members in the same order in their type codes. Remember, this part of the algorithm only applies if we are doing a structural comparison because of the lack of repository ids. I wanted to explicitly say that: union Foo switch(boolean) { case true: short s; case false: long l; }; and union Foo switch(boolean) { case false: long l; case true: short s; }; are not structurally equivalent, even though they are arguably so. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 17 Jul 1998 16:20:00 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Final proposal for Issue 665 (edits version) On Thu, 16 Jul 1998, Jonathan Biggar wrote: > > "The structural comparison only calls operations that are > > valid for the given TypeCode kind." > > > > I think it is redundant because if it called operations that are > not > > valid for a particular kind, the implementation would be buggy. > > It never hurts to be explicit... Yes, but it hurts to state the obvious... I will bow to the editor's decision of course :-) > > We have a change on in the interop RTF up for vote that requires type codes > > to preserve the order of union members when marshaled. So far, no-one > > has objected. If that change is accepted, the note about the order of > > union members can be removed, because all unions of the same type will > > have the members in the same order in their type codes. > > Remember, this part of the algorithm only applies if we are doing a > structural comparison because of the lack of repository ids. I wanted > to explicitly say that: > > union Foo switch(boolean) { > case true: short s; > case false: long l; > }; > > and > > union Foo switch(boolean) { > case false: long l; > case true: short s; > }; > > are not structurally equivalent, even though they are arguably so. Ah, misunderstanding. I would probably work this out as a separate example, because it is so unusual (unions are *evil* -- every time we touch the silly things we find yet another stupid special case that has to be dealt with...) And I agree with you, the above two unions are not equivalent. 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 Return-Path: Sender: jon@floorboard.com Date: Thu, 16 Jul 1998 22:36:45 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Final proposal for Issue 665 (edits version) Here is the proposal for Issue 665 as a list of edits to CORBA 2.2: Replace the first paragraph of 8.7.2 with: For IDL type declarations (typedef, struct, union, enum and interfaces), the IDL compiler will (if asked) produce a declaration of a TypeCode constant. See the language mapping rules for more information about the names of the generated TypeCode constants. TypeCode constants will include tk_alias definitions wherever an IDL typedef is referenced. These constants can be used with the dynamic invocation interface, and any other routines that require TypeCodes. -------------------------------------------------------------------------------- In secion 3.8.2 following to the paragraph describing the any type: An any logically contains a TypeCode (see 8.7) and a value that is described by the TypeCode. Each IDL language mapping will provide operations that allow programers to insert and access the TypeCode and value contained in an any. -------------------------------------------------------------------------------- Add the following operations to the TypeCode interface definition in both sections 8.7 and 8.8, right after the equal operation: ... interface TypeCode { ... boolean equivlant(in TypeCode tc); TypeCode get_compact_typecode(); .... }; -------------------------------------------------------------------------------- Add the following text to section 8.7 right after the description of the equal operation: The equivalent operation is used by the ORB when determining type equivalence for values stored in an IDL any. TypeCodes are considered equivalent based on the following semantics: a) if the result of the kind operation on either TypeCode is tk_alias, recursively replace the TypeCode with the result of calling content_type, until the kind is no longer tk_alias. b) If results of the kind operation on each typecode differ, equivalent returns false. c) If the id operation is valid for the TypeCode kind, equivalent returns true if the results of id for both TypeCodes are non-empty strings and both strings are equal. If either or both id is an empty string, the equivalent will perform a structural comparison of the TypeCodes by comparing the results of the other TypeCode operations in steps d through g. The structural comparison only calls operations that are valid for the given TypeCode kind. If any of these operations do not return equal results, then equivalent returns false. d) The results of the name and member_name operations are ignored and not compared. e) The results of the member_count, discriminator_type, default_index, length, digits and scale operations are compared. f) The results of the member_label operation for each member index of a union TypeCode are compared for equality. Note that this means that unions whose members are not defined in the same order are not considered equivalent. g) The results of the member_type operation for each member index, and the result of the content_type operation are compared by recursively calling equivalent. If the programmer needs to distinguish between a type and/or different aliases of that type, he can supplement equivalent by directly invoking the id operation and comparing the results. The get_compact_typecode operation strips out all optional name & member name fields, but it leaves all alias typecodes intact. -------------------------------------------------------------------------------- Add the following operation to the Repository interface in section 8.5.6 as well as section 8.8, right after the lookup_id operation: interface Repository { ... TypeCode get_canonical_typecode(in TypeCode tc); }; -------------------------------------------------------------------------------- Add the following paragraph to section 8.8, right after the description of the lookup_id operation: The get_canonical_typecode operation looks up the TypeCode in the Interface Repository and returns the an equivalent TypeCode including all repository ids, names, and member_names. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode. -------------------------------------------------------------------------------- Change the last paragraph of the description of the DynAny::assign operation, section 7.2.3 to: If an invalid DynAny object is passed (it has a typecode that is not equivalent or doesn't contain a meaningful value), the Invalid exception is returned. -------------------------------------------------------------------------------- Change the last paragraph of the description of the DynAny::from_any operation, section 7.2.3 to: If an invalid any is passed (it has a typecode that is not equivalent, or hasn't been assigned a value) the Invalid exception is returned. -------------------------------------------------------------------------------- Add the following paragraph right after the third paragraph of description of the "Accessing a value of some basic type in a DynAny object" in section 7.2.3: A type is consistent for inserting or extracting a value if its TypeCode is equivalent to the TypeCode contained in the DynAny. -------------------------------------------------------------------------------- Add the following paragraph to the description of the DynAny::current_component operation in section 7.2.3, right after the first paragraph: The TypeCode of the component DynAny will be the corresponding member_type or component_type of the TypeCode of the parent DynAny. -------------------------------------------------------------------------------- I think that covers everything. I'd appreciate it if other RTF members could look this over and suggest improved wording or identify anything I have missed. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Javier Lopez-Martin Subject: Re: OMG:Final version of Issue 665 proposal (prose form) To: jon@floorboard.com Date: Thu, 16 Jul 1998 23:44:23 MDT Cc: orb_revision@omg.org Hi Jon, Only minor improvements/precissions on the proposed text. It is correct, but imprecise/incomplete in some areas: > ---------------------------------------------------------------------------- > Proposal: > > 1. Make RepositoryIds mandatory for all TypeCodes that have them. [This > was done by the previous core RTF. I am just reiterating it here for > completeness.] > > 2. All TypeCode constants generated by the IDL compiler, as well as all > TypeCodes returned by the Interface Repository must include alias > TypeCodes wherever a typedef declaration appears in the original IDL > source. > > 3. Each IDL programming language mapping must provide a mechanism for > the programmer to ensure that values of the IDL any type contain the > exact typecode desired by the programmer. [NOTE: Is the resolution of this in the list that the C++ RTF is going to do for 2.3? I think it would be very important.] > 4. Since name and member_name fields are considered local to the > Interface Repository, these fields are never considered as > significant > for TypeCode equivalence comparison. > > 5. Define a new equivalent operation for TypeCodes: > > pseudo interface TypeCode { > ... > boolean equivalent(in TypeCode other); > ... > }; > > with the following semantics for comparing the two TypeCodes: > > a) if the result of the kind operation on either TypeCode is > tk_alias, > recursively replace the TypeCode with the result of calling > content_type, until the kind is no longer tk_alias. > > b) If results of the kind operation on each typecode differ, > equivalent > returns false. If no other typecode operations are valid for the kind, then equivalent returns true. > c) If the id operation is valid for the TypeCode kind, equivalent > returns true if the results of id for both TypeCodes are non-empty > strings and both strings are equal. If both strings are non-empty, but differ, then equivalen returns false. > If either or both id is an empty > string, the equivalent will perform a structural comparison of the ^^^ then > TypeCodes by comparing the results of the other TypeCode operations > in > steps d through g. The structural comparison only calls operations > that > are valid for the given TypeCode kind. If any of these operations > do > not return equal results, then equivalent returns false. Note that steps d to g might be also required for typecodes without id (sequence/array). Maybe we should make this more apparent, and keep the structural comparison separate? > d) The results of the name and member_name operations are ignored and > not compared. > > e) The results of the member_count, discriminator_type, default_index, > length, digits and scale operations are compared. > > f) The results of the member_label operation for each member index of a > union TypeCode are compared for equality. Note that this means that > unions whose members are not defined in the same order are not > considered equivalent. > > g) The results of the member_type operation for each member index, and > the result of the content_type operation are compared by recursively > calling equivalent. > > 6. The ORB uses TypeCode::equivalent for all internal TypeCode > comparisons, such as for supporting any (and thus DII and DSI) and > DynAny. I would remove the word "all" from the above, to accomodate Bob's comments (and the fact that equal() is required for some situations that Michi identified). > 7. If the programmer needs to distinguish between a type and/or > different aliases of that type, he can call TypeCode::id() and > compare > the RepositoryIds. > > 8. All DynAny insert & get operations do not consider aliases as > significant. The type() operation however, will return the TypeCode > with all of the aliases intact, including type() from any DynAny > member > components. DynAny::assign() and DynAny::from_any compare the > internal > TypeCode of the DynAny with the TypeCode of its argument using > TypeCode::equivalent() and raise Invalid if equivalent() returns > false. > Otherwise, the DynAny receives the new value but always retains its > original TypeCode. > > 9. Define a new operation: > > pseudo interface TypeCode { > ... > TypeCode get_compact_typecode(); > ... > }; > > The get_compact_typecode operation strips out all optional name & > member > name fields; it leaves all alias typecodes intact. > > Also add the following operation to CORBA::Repository: > > interface Repository { > ... > TypeCode get_canonical_typecode(in TypeCode tc); > ... > }; > > The get_canonical_typecode operation looks up the TypeCode in the > Interface Repository and returns the full TypeCode including all > repository ids, names, and member_names. If the top level TypeCode > does > not contain a RepositoryId, (such as array and sequence TypeCodes, > or > TypeCodes from older ORBs), then a new TypeCode is constructed by > recursively calling get_canonical_typecode on each member TypeCode > of > the original TypeCode. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Sender: jon@floorboard.com Date: Fri, 17 Jul 1998 11:13:39 -0700 From: Jonathan Biggar To: orb_revision@omg.org, jis@fpk.hp.com Subject: New version of the Issue 665 Proposal Here is the latest proposal for Issue 665 as a list of edits to CORBA 2.2. It incorporates comments made last night by Michi and Javier: A. Minor grammar cleanup. B. Added missing cases to equivalence algorithm. C. I'm no longer posting the "prose" version of the proposal, since the edits are the official version. -------------------------------------------------------------------------------- Replace the first paragraph of 8.7.2 with: For IDL type declarations (typedef, struct, union, enum and interfaces), the IDL compiler produces (if asked) a declaration of a TypeCode constant. See the language mapping rules for more information about the names of the generated TypeCode constants. TypeCode constants include tk_alias definitions wherever an IDL typedef is referenced. These constants can be used with the dynamic invocation interface and other routines that require TypeCodes. -------------------------------------------------------------------------------- In section 3.8.2 following to the paragraph describing the any type: An any logically contains a TypeCode (see 8.7) and a value that is described by the TypeCode. Each IDL language mapping provides operations that allow programers to insert and access the TypeCode and value contained in an any. -------------------------------------------------------------------------------- Add the following operations to the TypeCode interface definition in both sections 8.7 and 8.8, right after the equal operation: ... interface TypeCode { ... boolean equivalent(in TypeCode tc); TypeCode get_compact_typecode(); .... }; -------------------------------------------------------------------------------- Add the following text to section 8.7 right after the description of the equal operation: The equivalent operation is used by the ORB when determining type equivalence for values stored in an IDL any. TypeCodes are considered equivalent based on the following semantics: a) if the result of the kind operation on either TypeCode is tk_alias, recursively replace the TypeCode with the result of calling content_type, until the kind is no longer tk_alias. b) If results of the kind operation on each typecode differ, equivalent returns false. c) If the id operation is valid for the TypeCode kind, equivalent returns true if the results of id for both TypeCodes are non-empty strings and both strings are equal. If both ids are non-empty but are not equal, then equivalent returns false. If either or both id is an empty string, or the TypeCode kind does not support the id operation, equivalent will perform a structural comparison of the TypeCodes by comparing the results of the other TypeCode operations in steps d through g. The structural comparison only calls operations that are valid for the given TypeCode kind. If any of these operations do not return equal results, then equivalent returns false. If all comparisons are equal, equivalent returns true. d) The results of the name and member_name operations are ignored and not compared. e) The results of the member_count, discriminator_type, default_index, length, digits and scale operations are compared. f) The results of the member_label operation for each member index of a union TypeCode are compared for equality. Note that this means that unions whose members are not defined in the same order are not considered structurally equivalent. g) The results of the member_type operation for each member index, and the result of the content_type operation are compared by recursively calling equivalent. Applications that need to distinguish between a type and different aliases of that type can supplement equivalent by directly invoking the id operation and comparing the results. The get_compact_typecode operation strips out all optional name & member name fields, but it leaves all alias typecodes intact. -------------------------------------------------------------------------------- Add the following operation to the Repository interface in section 8.5.6 as well as section 8.8, right after the lookup_id operation: interface Repository { ... TypeCode get_canonical_typecode(in TypeCode tc); }; -------------------------------------------------------------------------------- Add the following paragraph to section 8.8, right after the description of the lookup_id operation: The get_canonical_typecode operation looks up the TypeCode in the Interface Repository and returns an equivalent TypeCode that includes all repository ids, names, and member_names. If the top level TypeCode does not contain a RepositoryId, such as array and sequence TypeCodes, or TypeCodes from older ORBs, then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode. -------------------------------------------------------------------------------- Change the last paragraph of the description of the DynAny::assign operation, section 7.2.3 to: If an invalid DynAny object is passed (a DynAny with a typecode that is not equivalent or doesn't contain a meaningful value), the Invalid exception is returned. -------------------------------------------------------------------------------- Change the last paragraph of the description of the DynAny::from_any operation, section 7.2.3 to: If an invalid any is passed (an any with a typecode that is not equivalent, or hasn't been assigned a value) the Invalid exception is returned. -------------------------------------------------------------------------------- Add the following paragraph right after the third paragraph of description of the "Accessing a value of some basic type in a DynAny object" in section 7.2.3: A type is consistent for inserting or extracting a value if its TypeCode is equivalent to the TypeCode contained in the DynAny. -------------------------------------------------------------------------------- Add the following paragraph to the description of the DynAny::current_component operation in section 7.2.3, right after the first paragraph: The TypeCode of the component DynAny is the corresponding member_type or component_type of the TypeCode of the parent DynAny. -------------------------------------------------------------------------------- -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 20 Jul 1998 14:58:53 -0400 From: Bob Kukura Organization: IONA Technologies To: jis@fpk.hp.com CC: orb_revision@omg.org Subject: orb_revision vote 4 votes and friendly ammendments IONA/Martin votes YES on 913, 999, 1088, 1541, and 1688. On 665, we vote YES provided that two minor friendly amendments are incorporated: 1) Comparison of the discriminator_type() for unions should be handled in step g) rather than step e), since it requires use of equivalent(). 2) The get_canonical_typecode() text needs to specify what happens if a RepositoryId is not found. I'd recommend adding the words in brackets: "If the top level TypeCode does not contain a RepositoryId, such as array and sequence TypeCodes, or TypeCodes from older ORBs, [or if it contains a RepositoryId that is not found in the target Repository,] then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode". On 1258, we vote YES with one very minor friendly amendment incorporated: Change "If FOO is an IDL type declaration, the IDL compiler with produce a declaration of a TypeCode constant" to "For each IDL type declaration, the IDL compiler will produce a declaration of a TypeCode constant". Nothing else seems to refer to "FOO". -Bob Return-Path: Sender: jon@floorboard.com Date: Mon, 20 Jul 1998 12:58:46 -0700 From: Jonathan Biggar To: Bob Kukura CC: jis@fpk.hp.com, orb_revision@omg.org Subject: Re: orb_revision vote 4 votes and friendly ammendments References: <35B3936D.ABCAE5EA@iona.com> Bob Kukura wrote: > > IONA/Martin votes YES on 913, 999, 1088, 1541, and 1688. > > On 665, we vote YES provided that two minor friendly amendments are > incorporated: > > 1) Comparison of the discriminator_type() for unions should be > handled > in step g) rather than step e), since it requires use of > equivalent(). Right. Somehow I got it into my head that the discriminator_type() returned a TCKind instead of a TypeCode. I have no problem with this change. > 2) The get_canonical_typecode() text needs to specify what happens if a > RepositoryId is not found. I'd recommend adding the words in brackets: > "If the top level TypeCode does not contain a RepositoryId, such as > array and sequence TypeCodes, or TypeCodes from older ORBs, [or if it > contains a RepositoryId that is not found in the target Repository,] > then a new TypeCode is constructed by recursively calling > get_canonical_typecode on each member TypeCode of the original > TypeCode". This is also a good change. > On 1258, we vote YES with one very minor friendly amendment > incorporated: Change "If FOO is an IDL type declaration, the IDL > compiler with produce a declaration of a TypeCode constant" to "For > each > IDL type declaration, the IDL compiler will produce a declaration of > a > TypeCode constant". Nothing else seems to refer to "FOO". No problem with this one either. I never liked the FOO in the first place. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jis@fpk.hp.com Date: Mon, 20 Jul 1998 16:33:40 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jonathan Biggar Cc: Bob Kukura , jis@fpk.hp.com, orb_revision@omg.org Subject: Re: orb_revision vote 4 votes and friendly ammendments References: <35B3936D.ABCAE5EA@iona.com> <35B3A176.CC34AFC7@floorboard.com> Jonathan Biggar wrote: > Bob Kukura wrote: > > > > IONA/Martin votes YES on 913, 999, 1088, 1541, and 1688. > > > > On 665, we vote YES provided that two minor friendly amendments > are > > incorporated: > > > > 1) Comparison of the discriminator_type() for unions should be > handled > > in step g) rather than step e), since it requires use of > equivalent(). > > Right. Somehow I got it into my head that the discriminator_type() > returned a TCKind instead of a TypeCode. I have no problem with > this > change. > > > 2) The get_canonical_typecode() text needs to specify what happens > if a > > RepositoryId is not found. I'd recommend adding the words in > brackets: > > "If the top level TypeCode does not contain a RepositoryId, such > as > > array and sequence TypeCodes, or TypeCodes from older ORBs, [or if > it > > contains a RepositoryId that is not found in the target > Repository,] > > then a new TypeCode is constructed by recursively calling > > get_canonical_typecode on each member TypeCode of the original > > TypeCode". > > This is also a good change. > > > On 1258, we vote YES with one very minor friendly amendment > > incorporated: Change "If FOO is an IDL type declaration, the IDL > > compiler with produce a declaration of a TypeCode constant" to > "For each > > IDL type declaration, the IDL compiler will produce a declaration > of a > > TypeCode constant". Nothing else seems to refer to "FOO". > > No problem with this one either. I never liked the FOO in the first > place. :-) Great, so unless I hear hwols of complaints from any of the others that have already voted YES on 665 about these minor changes, I will record the votes as YES for the modified 665 as above. However, please note that we will have to address a minor overlap issue between 665 and 1258 on Thursday anyway. This has to do with the fact that both propose a replacement first paragraph for 8.7.2, actually the para that Bob has complained about above. the current proposal is to use the proposed first paragraph from the resolution for 665, but with the first parantheses eliminated. So the new first paragraph will read: "For IDL type declarations the IDL compiler produces (if asked) a declaration of a TypeCode constant. See the language mapping rules for more information about the names of the generated TypeCode constants. TypeCode constants include tk_alias definitions wherever an IDL typedef is referenced. These constants can be used with the dynamic invocation interface and other routines that require TypeCodes. " which basically addresses Bob's concern anyway. Thanks, Jishnu. Ps. Bob, I am recording your vote as YES on all with the minor mods, unless of course someone goes balistic over these changes. Date: Mon, 15 Feb 1999 21:24:04 -0800 From: Jonathan Biggar Organization: Floorboard Software X-Accept-Language: en To: Jishnu Mukerji CC: Jeff Mischkinsky , "Robert A. Kukura" , Tom Rutt , Jonathan Biggar , Ken Fleming , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 3 References: <36C48D53.80DE0F33@fpk.hp.com> Jishnu Mukerji wrote: > Core RTF 2.4 voters, the vote is due on Friday the 19th of Feb by 17:00 > EST (GMT-5). Before I vote, I had a couple of questions on a couple of the issues: Issue 569: The new text has more information, but it still doesn't read very well. The new definition of a Request appears to be self recursive, and doesn't really seem to meet my common sense notion of what a request is. Issue 665a: It's not clear what we are voting on here? Is it to recommend that the interop RTF adopt the propose text? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Date: Wed, 17 Feb 1999 11:37:44 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jonathan Biggar CC: Jeff Mischkinsky , "Robert A. Kukura" , Tom Rutt , Jonathan Biggar , Ken Fleming , Stephen McNamara , Randy Fox , Bill Janssen , Michi Henning , Juan Jose Hierro Sureda , Bill Beckwith , Paul Kyzivat , Ken Cavanaugh , Edward Cobb , orb_revision@omg.org Subject: Re: Core RTF 2.4 Vote 3 References: <36C48D53.80DE0F33@fpk.hp.com> <36C900F4.5D298F4D@floorboard.com> Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > Core RTF 2.4 voters, the vote is due on Friday the 19th of Feb by > 17:00 > > EST (GMT-5). > > Before I vote, I had a couple of questions on a couple of the > issues: > > Issue 569: The new text has more information, but it still doesn't > read > very well. The new definition of a Request appears to be self > recursive, > and doesn't really seem to meet my common sense notion of what a > request > is. I know, any suggestions to improve is most welcome. I was merely trying to disambiguate the use of Request as referring to the (a) initiating event, and (b) the entire causally connected collection of events that are set off by the event that initiates the request. The text that is present in the 2.3 spec is almost worse than confusing. Perhaps we should invent a new term for what (b) is, 'cause that is the concept that the para seems to want to talk about. > Issue 665a: It's not clear what we are voting on here? Is it to recommend > that the interop RTF adopt the propose text? Yes. I have talked to Tom and he will take all these recommendations and try to get them through the Interop RTF. I thought it is better to propose concrete language rather than just say "fix it". Of course, the the most fortuitious circumstance that a vast majority of the voters on Interop RTF are also voters on the Core RTF makes it very likely that something that is recommended out of the Core RTF will also pass the Interop RTF. Regards, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA.