Issue 1928: Proposal for creating recursive TypeCodes (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: We have spent some time pondering the various issues surrounding recursive TypeCodes and OBV, and have come up with a proposed solution. This is not a formal proposal (it does not include actual changes to the CORBA spec) and is intended mostly to promote discussion. For this discussion a recursive TypeCode is defined as a TypeCode which contains data members which refer to the containing type or any type containing the containg type. The basic problem of creating recursive TypeCodes has become more complex with the addition of valuetypes. The current mechanism for creating TypeCodes (as adopted by the last RTF) cannot create TypeCodes for a large number of cases, and can be quite confusing. The new proposal solves the problem of creating recursive TypeCodes in general and would deprecate all existing mechanisms for creating recursive TypeCodes. Resolution: Revised Text: Actions taken: September 2, 1998: received issue February 22, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: "George Scott" Date: Tue, 01 Sep 1998 19:31:42 -0700 From: "George M. Scott" Organization: Inprise Corporation To: obv-rtf@omg.org, orb_revision@omg.org Subject: Proposal for creating recursive TypeCodes We have spent some time pondering the various issues surrounding recursive TypeCodes and OBV, and have come up with a proposed solution. This is not a formal proposal (it does not include actual changes to the CORBA spec) and is intended mostly to promote discussion. For this discussion a recursive TypeCode is defined as a TypeCode which contains data members which refer to the containing type or any type containing the containg type. The basic problem of creating recursive TypeCodes has become more complex with the addition of valuetypes. The current mechanism for creating TypeCodes (as adopted by the last RTF) cannot create TypeCodes for a large number of cases, and can be quite confusing. The new proposal solves the problem of creating recursive TypeCodes in general and would deprecate all existing mechanisms for creating recursive TypeCodes. The new proposal would add the following definitions to CORBA: module CORBA { typedef StructMember RecursiveMember; typedef sequence RecursiveMemberSeq; // PIDL interface ORB { ... void fill_in_recursive_tc(in TypeCode tc, in RecursiveMemberSeq replacement_fields); ... }; }; The fill_in_recursive_tc method replaces the create_recursive_value_tc method, and would deprecate the create_recursive_sequence_tc method. The new method can be called on TypeCodes representing valuetypes, structs, unions, and exceptions (all types which contain member fields). The purpose of the method is to replace the TypeCode and IDLType fields of a member field of a previously created TypeCode. The change would allow one to call create_struct_tc, create_union_tc, create_exception_tc, and create_valuetype_tc, with partial type information which could be filled in later with a call to fill_in_recursive_tc. When calling the create_*_tc methods one must specify all information for a member, except one can optionally use tk_null for the TypeCode instead of the correct value, and a null object reference for the IDLType field (I think this is always allowed). A TypeCode created in this manner is not considered valid, until it is later "filled in" with the correct Type information for all members which have a tk_null type. Here are three example creations: ----------------------------------------------------------------- // Example 1 provided by Leo Uzcategui (leou@us.ibm.com) // IDL valuetype v; valuetype w; struct s { v a; w b; }; valuetype v { public s c; }; valuetype w { public s d; }; // (pseudo) Java TypeCode null_tc = orb.get_primitive_tc(TCKind.tk_null); StructMember sm[] = new StructMember[2]; sm[0] = new StructMember("a", null_tc, null); sm[1] = new StructMember("b", null_tc, null); TypeCode s_tc = orb.create_struct_tc("IDL:s:1.0", "s", sm); ValueMember vm[] = new ValueMember[1]; vm[0] = new ValueMember("c", "", "", "", s_tc, null, PUBLIC_MEMBER); TypeCode v_tc = orb.create_valuetype_tc("IDL:v:1.0", "v", VTM_NONE, null_tc, vm); vm = new ValueMember[1]; vm[0] = new ValueMember("d", "", "", "", s_tc, null, PUBLIC_MEMBER); TypeCode w_tc = orb.create_valuetype_tc("IDL:w:1.0", "w", VTM_NONE, null_tc, vm); StructMember rm[] = new StructMember[2]; rm[0] = new StructMember("a", v_tc, null); rm[1] = new StructMember("b", w_tc, null); orb.fill_in_recursive_tc(s_tc, rm); ------------------------------------------------------- // Example 2 co-recursive values // IDL valuetype B; valuetype A { public B x; public long l; }; valuetype B { public A y; }; // (pseudo) Java TypeCode null_tc = orb.get_primitive_tc(TCKind.tk_null); ValueMember vm[] = new ValueMember[2]; vm[0] = new ValueMember("x", "", "", "", null_tc, null, PUBLIC_MEMBER); vm[0] = new ValueMember("l", "", "", "", orb.get_primitive_tc(TCKind.tk_long), null, PUBLIC_MEMBER); TypeCode a_tc = orb.create_valuetype_tc("IDL:A:1.0", "A", VTM_NONE, null_tc, vm); vm = new ValueMember[1]; vm[0] = new ValueMember("y", "", "", "", null_tc, null, PUBLIC_MEMBER); TypeCode b_tc = orb.create_valuetype_tc("IDL:B:1.0", "B", VTM_NONE, null_tc, vm); StructMember rm[] = new StructMember[1]; rm[0] = new StructMember("x", b_tc, null); orb.fill_in_recursive_tc(a_tc, rm); rm = new StructMember[1]; rm[0] = new StructMember("y", a_tc, null); orb.fill_in_recursive_tc(b_tc, rm); -------------------------------------------------- // Example 3 recurisve sequence // IDL struct A { long l; sequence s; }; // (pseudo) Java TypeCode null_tc = orb.get_primitive_tc(TCKind.tk_null); StructMember sm[] = new StructMember[2]; sm[0] = new StructMember("l", orb.get_primitive_tc(TCKind.tk_long), null); sm[1] = new StructMember("s", null_tc, null); TypeCode a_tc = orb.create_struct_tc("IDL:s:1.0", "s", sm); TypeCode seq_tc = orb.create_sequence_tc(0, a_tc); sm = new StructMember[1]; sm[0] = new StructMember("s", seq_tc, null); orb.fill_in_recursive_tc(a_tc, sm); ------------------------------------------------ Java helpers are generated as they are today, but require some additional synchronization logic to provide correct behavior while preventing deadlock in the type() method. The only issue with the Java mapping is that multiple threads calling a recursive value helper's type() method may get a typecode which is not yet valid (because another thread is still filling it in). If deemed important enough, we can also fix this problem by adding some additional APIs to the Helper class for recursive types, which could properly synchronize TypeCode creation so that type() always returns a completely filled in TypeCode. George Return-Path: Sender: jon@floorboard.com Date: Tue, 01 Sep 1998 20:36:41 -0700 From: Jonathan Biggar To: "George M. Scott" CC: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Proposal for creating recursive TypeCodes References: <35ECAE0E.8FD5D900@inprise.com> George M. Scott wrote: > > We have spent some time pondering the various issues surrounding > recursive TypeCodes and OBV, and have come up with a proposed > solution. This is not a formal proposal (it does not include actual > changes to the CORBA spec) and is intended mostly to promote > discussion. [ You wanted discussion? :-) ] I'll have to say right out that I don't like this proposal at all, because it precludes several implementation strategies for TypeCodes, and requires an "action at a distance" mechanism that is less than straightforward. Here is a thought, however: are all targets of recursion required to have a repository id? I see you have called out struct, union, exceptions and valuetypes as possible targets of recursion. Are there any others? If this is the case, here is a counter proposal: module CORBA { ... interface ORB { ... TypeCode create_recursive_typecode(in RepositoryID id); ... }; ... }; This would operate like the existing create_recursive_tc() in that it would be embedded into other typecodes. Once it was embedded in a typecode that matched the same repository id, the recursion would be completed. I'll think about this idea overnight, as maybe come up with an example or two. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 01 Sep 1998 23:27:33 -0400 To: "George M. Scott" From: Steve Vinoski Subject: Re: Proposal for creating recursive TypeCodes Cc: obv-rtf@omg.org, orb_revision@omg.org At 07:31 PM 9/1/98 -0700, George M. Scott wrote: >The basic problem of creating recursive TypeCodes has become more >complex with the addition of valuetypes. The current mechanism for >creating TypeCodes (as adopted by the last RTF) cannot create >TypeCodes for a large number of cases, and can be quite confusing. >The new proposal solves the problem of creating recursive TypeCodes in >general and would deprecate all existing mechanisms for creating >recursive TypeCodes. > >The new proposal would add the following definitions to CORBA: > >module CORBA { > > typedef StructMember RecursiveMember; > typedef sequence RecursiveMemberSeq; > > // PIDL > interface ORB { > ... > void fill_in_recursive_tc(in TypeCode tc, > in RecursiveMemberSeq replacement_fields); > ... > }; > >}; > >The fill_in_recursive_tc method replaces the create_recursive_value_tc >method, and would deprecate the create_recursive_sequence_tc method. >The new method can be called on TypeCodes representing valuetypes, >structs, unions, and exceptions (all types which contain member >fields). The purpose of the method is to replace the TypeCode and >IDLType fields of a member field of a previously created TypeCode. As I argued in the previous RTF, TypeCodes should not be mutable like this. First of all, if you were going to allow for the modification of a TypeCode, why would the ORB need to be involved at all? Basic OO programming principles would have the method on TypeCode itself, not on ORB. Secondly, today there are no mutation operations on TypeCode, and I think for consistency we should continue to avoid introducing them. Thirdly, though TypeCodes are handled like objects, they are really more like valuetypes, so passing one as an "in" and having it change is pretty weird. I counterpropose: TypeCode create_recursive_tc(in TypeCode incomplete_tc, in RecursiveMemberSeq replacement_fields); The returned TypeCode would be the same as the incomplete_tc argument but with the replacement fields filled in. >Java helpers are generated as they are today, but require some >additional synchronization logic to provide correct behavior while >preventing deadlock in the type() method. The only issue with the >Java mapping is that multiple threads calling a recursive value >helper's type() method may get a typecode which is not yet valid >(because another thread is still filling it in). If deemed important >enough, we can also fix this problem by adding some additional APIs to >the Helper class for recursive types, which could properly synchronize >TypeCode creation so that type() always returns a completely filled in >TypeCode. This problem goes away with my counterproposal. --steve Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 01 Sep 1998 23:30:29 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Proposal for creating recursive TypeCodes Cc: obv-rtf@omg.org, orb_revision@omg.org References: <35ECAE0E.8FD5D900@inprise.com> At 08:36 PM 9/1/98 -0700, Jonathan Biggar wrote: >I'll have to say right out that I don't like this proposal at all, >because it precludes several implementation strategies for TypeCodes, >and requires an "action at a distance" mechanism that is less than >straightforward. As my other message points out, I agree completely. >Here is a thought, however: are all targets of recursion required to >have a repository id? I see you have called out struct, union, >exceptions and valuetypes as possible targets of recursion. Are there >any others? > >If this is the case, here is a counter proposal: > >module CORBA { > ... > interface ORB { > ... > TypeCode create_recursive_typecode(in RepositoryID id); > ... > }; > ... >}; > >This would operate like the existing create_recursive_tc() in that it >would be embedded into other typecodes. Once it was embedded in a >typecode that matched the same repository id, the recursion would be >completed. Uncanny. I was also thinking precisely the same thing, so needless to say, I like it. :-) --steve Return-Path: Date: Wed, 02 Sep 1998 14:04:49 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: "George M. Scott" Cc: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Proposal for creating recursive TypeCodes References: <35ECAE0E.8FD5D900@inprise.com> George, A couple of minor comments. 1. create_valuetype_tc should be create_value_tc. 2. It would be helpful if you could show how the code to create value TypeCodes is packaged into Java helper type() methods. This might expose some interesting issues to do with type() methods returning partially constructed versus fully constructed TypeCodes, such as the ones you referred to in your last paragraph. It would also be interesting to see how much special code is needed in type() methods to take acccount of the recursive case. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Sender: "George Scott" Date: Wed, 09 Sep 1998 18:48:12 -0700 From: "George M. Scott" Organization: Inprise Corporation To: Jonathan Biggar CC: obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Proposal for creating recursive TypeCodes References: <35ECAE0E.8FD5D900@inprise.com> <35ECBD49.E357677@floorboard.com> Jonathan Biggar wrote: > > > If this is the case, here is a counter proposal: > > module CORBA { > ... > interface ORB { > ... > TypeCode create_recursive_typecode(in RepositoryID id); > ... > }; > ... > }; > > This would operate like the existing create_recursive_tc() in that > it > would be embedded into other typecodes. Once it was embedded in a > typecode that matched the same repository id, the recursion would be > completed. OK, we agree this proposal as well. It will require a small change to the Java language mapping to handle reentrancy issues, but otherwise we think this solution will work. I will post some sample Java helper classes later in the week, along with the required changes to the Java language mapping. George Return-Path: Sender: jis@fpk.hp.com Date: Thu, 10 Sep 1998 15:53:26 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: "George M. Scott" Cc: Jonathan Biggar , obv-rtf@omg.org, orb_revision@omg.org Subject: Re: Proposal for creating recursive TypeCodes References: <35ECAE0E.8FD5D900@inprise.com> <35ECBD49.E357677@floorboard.com> <35F72FDC.18B636AB@inprise.com> George M. Scott wrote: > > Jonathan Biggar wrote: > > > > > > If this is the case, here is a counter proposal: > > > > module CORBA { > > ... > > interface ORB { > > ... > > TypeCode create_recursive_typecode(in RepositoryID id); > > ... > > }; > > ... > > }; > > > > This would operate like the existing create_recursive_tc() in that > it > > would be embedded into other typecodes. Once it was embedded in a > > typecode that matched the same repository id, the recursion would > be > > completed. > > OK, we agree this proposal as well. It will require a small change > to the Java language mapping to handle reentrancy issues, but > otherwise > we think this solution will work. I will post some sample Java > helper > classes later in the week, along with the required changes to the > Java > language mapping. > > George So will someone please write me up a complete proposed resolution with proposed text changes so that i can include it on a vote. If you do it real quick - like between now and 12noon EDT Friday we might even get it in the vote that goes out tomorrow. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group 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.