Issue 2235: uses of recursive_tc (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53, "Once the recursive TypeCode has been properly embedded in the enclosing TypeCode which corresponds to the specified repository id, it will function as a normal TypeCode." Given the following idl: valuetype v { public v m0; }; And the following C++ code to generate the typecode for v: CORBA::ORB_ptr orb = ...; CORBA::TypeCode_ptr tcRecursive = orb->create_recursive_tc("IDL:v:1.0"); CORBA::ValueMemberSeq v_seq; v_seq.length(1); v_seq[0].type = tcRecursive; ... CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v", VM_NONE, CORBA::TypeCode::_nil(), v_seq); After tcRecursive has been properly embedded, what does "tcRecursive functioning like a normal TypeCode" mean? Does it mean that one can call on tcRecursive the same methods that are available on tcV? For example, will CORBA::Visibility vis = tcRecursive->member_visibility(0); work? Resolution: Close no change in 2.4 Revised Text: -currently, the spec says the embedded typecode is incomplete when constructed but must function as a real typecode when embedded. This requires implementers to perform some sort of delegation for a recursive tc. - the issue proposes that even once completed, the embedded typecode raise an exception whenever it is programmatically queried. In both scenarios, ORBs must implement a special typecode (the embedded one). In one case to do delegation, in the other to raise exceptions. Both wordings of the spec (the current wording and your proposal) impose a limitation on implementations of recursive typecodes. There doesn't appear to be any pressing reason to make the embedded typecode unusable if it can just as easily (and with some additional benefits for implementors who are using reference counting) perform the delegation so the wording should remain unchanged. Actions taken: December 3, 1998: received issue September 16, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: mcheng@us.ibm.com X-Lotus-FromDomain: IBMUS To: issues@omg.org, orb_revision@omg.org cc: amcleod@us.ibm.com, leou@us.ibm.com Date: Thu, 3 Dec 1998 09:36:11 -0600 Subject: uses of recursive_tc Content-Disposition: inline Hi, According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53, "Once the recursive TypeCode has been properly embedded in the enclosing TypeCode which corresponds to the specified repository id, it will function as a normal TypeCode." Given the following idl: valuetype v { public v m0; }; And the following C++ code to generate the typecode for v: CORBA::ORB_ptr orb = ...; CORBA::TypeCode_ptr tcRecursive = orb->create_recursive_tc("IDL:v:1.0"); CORBA::ValueMemberSeq v_seq; v_seq.length(1); v_seq[0].type = tcRecursive; ... CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v", VM_NONE, CORBA::TypeCode::_nil(), v_seq); After tcRecursive has been properly embedded, what does "tcRecursive functioning like a normal TypeCode" mean? Does it mean that one can call on tcRecursive the same methods that are available on tcV? For example, will CORBA::Visibility vis = tcRecursive->member_visibility(0); work? I would like to argue that the above should not work, that a recursive typecode should only be used as a place holder. Afterwards, the real typecode, tcV, is the one that the user should use as the normal TypeCode. Otherwise, there is unnecessary burden placed on the implementor, with no additional benefits. For the above example, the typecode data structure during construction looks like: v | member[0] | recursive_tc(v) (place holder) The implementation should have the freedom to remove the placeholder as follows: +--> v | | | member[0] | | +---+ But if we were to follow the spec literally, we have to ensure that the place holder still functions like a real typecode by forwarding all calls to it to the real typecode for v: +--> v <-----------------recursive_tc_(v) place holder | | | member[0] | | +---+ And we will be burdened with checking for the place holder in all typecode method implementations. Therefore, I would like to recommend that the wording be changed, to the effect that "The recursive TypeCode is only used as a place holder during TypeCode construction. It may not be used after it has been properly embedded." Michael Cheng mcheng@us.ibm.com Return-Path: Sender: "Jon Goldberg" Date: Thu, 03 Dec 1998 07:56:58 -0800 From: Jon Goldberg Reply-To: goldberg@inprise.com Organization: Visigenic Software, Inc. X-Accept-Language: en To: mcheng@us.ibm.com CC: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Subject: Re: uses of recursive_tc References: <852566CF.00563288.00@us.ibm.com> Hi Michael- Although your suggestion sounds cleaner, eliminating the "placeholder" typecode doesn't work in many cases in practice. The current wording allows your suggestion (replace the placeholder with the "real" typecode) or an implementation in which the placeholder typecode is maintained and just delegates all calls through to its "real" typecode. Your suggested wording eliminates the latter possibility and therefore invalidates valid implementations of typecodes. In particular, for languages without garbage collection such as C++, maintaining the distinct placeholder typecode may be the easiest way to manage memory. With your suggestion, there is no distinction between the different types of typecodes and a cycle is created when you replace the placeholder with a reference to the "real" typecode. I'd suggest that this issue be closed with no change to the specification wording. take care, Jon mcheng@us.ibm.com wrote: > > Hi, > > According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53, > "Once the recursive TypeCode has been properly embedded in the > enclosing TypeCode which corresponds to the specified > repository > id, it will function as a normal TypeCode." > > Given the following idl: > > valuetype v { > public v m0; > }; > > And the following C++ code to generate the typecode for v: > > CORBA::ORB_ptr orb = ...; > CORBA::TypeCode_ptr tcRecursive = > orb->create_recursive_tc("IDL:v:1.0"); > CORBA::ValueMemberSeq v_seq; > v_seq.length(1); > v_seq[0].type = tcRecursive; > ... > CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v", > VM_NONE, > CORBA::TypeCode::_nil(), > v_seq); > > After tcRecursive has been properly embedded, what does "tcRecursive > functioning > like a normal TypeCode" mean? Does it mean that one can call on > tcRecursive the same > methods that are available on tcV? For example, will > > CORBA::Visibility vis = tcRecursive->member_visibility(0); > > work? > > I would like to argue that the above should not work, that a > recursive > typecode should > only be used as a place holder. Afterwards, the real typecode, tcV, > is the > one > that the user should use as the normal TypeCode. Otherwise, there > is > unnecessary > burden placed on the implementor, with no additional benefits. > > For the above example, the typecode data structure during > construction > looks like: > > v > | > member[0] > | > recursive_tc(v) (place holder) > > The implementation should have the freedom to remove the placeholder > as > follows: > > +--> v > | | > | member[0] > | | > +---+ > > But if we were to follow the spec literally, we have to ensure that > the > place holder still > functions like a real typecode by forwarding all calls to it to the > real > typecode for v: > +--> v <-----------------recursive_tc_(v) place holder > | | > | member[0] > | | > +---+ > > And we will be burdened with checking for the place holder in all > typecode > method > implementations. Therefore, I would like to recommend that the > wording be > changed, to the > effect that > "The recursive TypeCode is only used as a place holder during > TypeCode > construction. > It may not be used after it has been properly embedded." > > Michael Cheng > mcheng@us.ibm.com Return-Path: From: mcheng@us.ibm.com X-Lotus-FromDomain: IBMUS To: goldberg@inprise.com cc: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Date: Fri, 4 Dec 1998 08:30:02 -0600 Subject: Re: uses of recursive_tc Content-Disposition: inline Hi Jon, My suggestion is aimed at making it possible to eliminate the placeholder during the resolution of embedded typecode, not to mandate it. I'm not sure that the current wording allows one to eliminate the placeholder, because an interpretation for "[the placeholder] function as a normal TypeCode" is that one can invoke methods on it explicitly. By changing the wording to say that the user may not make calls on the placeholder typecode, we introduce for the implementor the opportunity to remove it. Implementations that choose to keep the placeholder in place in the underlying data structure can still do so. It's just that the placeholder is hidden from the user, in that all calls are forwarded to the real underlying typecode. Michael Cheng mcheng@us.ibm.com Jon Goldberg on 12/03/98 09:56:58 AM Please respond to goldberg@inprise.com To: Michael Cheng/Austin/IBM cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo Uzcategui/Austin/IBM Subject: Re: uses of recursive_tc Hi Michael- Although your suggestion sounds cleaner, eliminating the "placeholder" typecode doesn't work in many cases in practice. The current wording allows your suggestion (replace the placeholder with the "real" typecode) or an implementation in which the placeholder typecode is maintained and just delegates all calls through to its "real" typecode. Your suggested wording eliminates the latter possibility and therefore invalidates valid implementations of typecodes. In particular, for languages without garbage collection such as C++, maintaining the distinct placeholder typecode may be the easiest way to manage memory. With your suggestion, there is no distinction between the different types of typecodes and a cycle is created when you replace the placeholder with a reference to the "real" typecode. I'd suggest that this issue be closed with no change to the specification wording. take care, Jon mcheng@us.ibm.com wrote: > > Hi, > > According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53, > "Once the recursive TypeCode has been properly embedded in the > enclosing TypeCode which corresponds to the specified repository > id, it will function as a normal TypeCode." > > Given the following idl: > > valuetype v { > public v m0; > }; > > And the following C++ code to generate the typecode for v: > > CORBA::ORB_ptr orb = ...; > CORBA::TypeCode_ptr tcRecursive = > orb->create_recursive_tc("IDL:v:1.0"); > CORBA::ValueMemberSeq v_seq; > v_seq.length(1); > v_seq[0].type = tcRecursive; > ... > CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v", > VM_NONE, CORBA::TypeCode::_nil(), > v_seq); > > After tcRecursive has been properly embedded, what does "tcRecursive > functioning > like a normal TypeCode" mean? Does it mean that one can call on > tcRecursive the same > methods that are available on tcV? For example, will > > CORBA::Visibility vis = tcRecursive->member_visibility(0); > > work? > > I would like to argue that the above should not work, that a recursive > typecode should > only be used as a place holder. Afterwards, the real typecode, tcV, is the > one > that the user should use as the normal TypeCode. Otherwise, there is > unnecessary > burden placed on the implementor, with no additional benefits. > > For the above example, the typecode data structure during construction > looks like: > > v > | > member[0] > | > recursive_tc(v) (place holder) > > The implementation should have the freedom to remove the placeholder as > follows: > > +--> v > | | > | member[0] > | | > +---+ > > But if we were to follow the spec literally, we have to ensure that the > place holder still > functions like a real typecode by forwarding all calls to it to the real > typecode for v: > +--> v <-----------------recursive_tc_(v) place holder > | | > | member[0] > | | > +---+ > > And we will be burdened with checking for the place holder in all typecode > method > implementations. Therefore, I would like to recommend that the wording be > changed, to the > effect that > "The recursive TypeCode is only used as a place holder during TypeCode > construction. > It may not be used after it has been properly embedded." > > Michael Cheng > mcheng@us.ibm.com Return-Path: Sender: "Jon Goldberg" Date: Fri, 04 Dec 1998 10:08:40 -0800 From: Jon Goldberg Reply-To: goldberg@inprise.com Organization: Visigenic Software, Inc. X-Accept-Language: en To: mcheng@us.ibm.com CC: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Subject: Re: uses of recursive_tc References: <852566D0.00502593.00@us.ibm.com> Hi- The word "eliminating" is somewhat problematic. The actual TypeCode exists until it is released (or no longer referenced) by the code you listed in your original message. The two questions in my mind are: 1) once you have completed the outer typecode, can you query your recursive typecode as if it a normal TypeCode? 2) once you have completed the outer typecode, will traversing that typecode return the exact same TypeCode object as you created initially? The current wording requires the answer to #1 to be "yes". How you do this is up to you, but that TypeCode is valid. The current wording allows the answer to #2 to be implementation dependent as long as the embedded recursive typecode you created is_equivalent to the one returned when you traverse the outer typecode. This may support your intention of "eliminating"... that the TypeCode is no longer part of the ORB implementation's graph of TypeCode objects. I argue that this is completely hidden from users and there is nothing in the current wording that prohibits it. Is there some aspect of "eliminating" that you are aiming for that I am missing? -Jon mcheng@us.ibm.com wrote: > > Hi Jon, > > My suggestion is aimed at making it possible to eliminate the > placeholder > during the resolution of embedded typecode, not to mandate it. > I'm not sure that the current wording allows one to eliminate the > placeholder, > because an interpretation for "[the placeholder] function as a > normal > TypeCode" is that one can invoke methods on it explicitly. > > By changing the wording to say that the user may not make calls on > the > placeholder typecode, we introduce for the implementor the > opportunity > to remove it. Implementations that choose to keep the placeholder > in place > in the underlying data structure can still do so. It's just that > the > placeholder > is hidden from the user, in that all calls are forwarded to the real > underlying > typecode. > > Michael Cheng > mcheng@us.ibm.com > > Jon Goldberg on 12/03/98 09:56:58 AM > > Please respond to goldberg@inprise.com > > To: Michael Cheng/Austin/IBM > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > Uzcategui/Austin/IBM > Subject: Re: uses of recursive_tc > > Hi Michael- > > Although your suggestion sounds cleaner, eliminating the > "placeholder" > typecode > doesn't work in many cases in practice. > > The current wording allows your suggestion (replace the placeholder > with the "real" typecode) or an implementation in which the > placeholder typecode is maintained and just delegates all calls > through to its "real" typecode. Your suggested wording eliminates > the latter possibility and therefore invalidates valid > implementations > of typecodes. > > In particular, for languages without garbage collection such as C++, > maintaining the distinct placeholder typecode may be the easiest > way to manage memory. With your suggestion, there is no distinction > between the different types of typecodes and a cycle is created when > you replace the placeholder with a reference to the "real" typecode. > > I'd suggest that this issue be closed with no change to the > specification wording. > > take care, > Jon > > mcheng@us.ibm.com wrote: > > > > Hi, > > > > According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53, > > "Once the recursive TypeCode has been properly embedded in the > > enclosing TypeCode which corresponds to the specified > repository > > id, it will function as a normal TypeCode." > > > > Given the following idl: > > > > valuetype v { > > public v m0; > > }; > > > > And the following C++ code to generate the typecode for v: > > > > CORBA::ORB_ptr orb = ...; > > CORBA::TypeCode_ptr tcRecursive = > > orb->create_recursive_tc("IDL:v:1.0"); > > CORBA::ValueMemberSeq v_seq; > > v_seq.length(1); > > v_seq[0].type = tcRecursive; > > ... > > CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", > "v", > > VM_NONE, > CORBA::TypeCode::_nil(), > > v_seq); > > > > After tcRecursive has been properly embedded, what does > "tcRecursive > > functioning > > like a normal TypeCode" mean? Does it mean that one can call on > > tcRecursive the same > > methods that are available on tcV? For example, will > > > > CORBA::Visibility vis = tcRecursive->member_visibility(0); > > > > work? > > > > I would like to argue that the above should not work, that a > recursive > > typecode should > > only be used as a place holder. Afterwards, the real typecode, > tcV, is > the > > one > > that the user should use as the normal TypeCode. Otherwise, there > is > > unnecessary > > burden placed on the implementor, with no additional benefits. > > > > For the above example, the typecode data structure during > construction > > looks like: > > > > v > > | > > member[0] > > | > > recursive_tc(v) (place holder) > > > > The implementation should have the freedom to remove the > placeholder as > > follows: > > > > +--> v > > | | > > | member[0] > > | | > > +---+ > > > > But if we were to follow the spec literally, we have to ensure > that the > > place holder still > > functions like a real typecode by forwarding all calls to it to > the real > > typecode for v: > > +--> v <-----------------recursive_tc_(v) place holder > > | | > > | member[0] > > | | > > +---+ > > > > And we will be burdened with checking for the place holder in all > typecode > > method > > implementations. Therefore, I would like to recommend that the > wording > be > > changed, to the > > effect that > > "The recursive TypeCode is only used as a place holder during > TypeCode > > construction. > > It may not be used after it has been properly embedded." > > > > Michael Cheng > > mcheng@us.ibm.com Return-Path: From: mcheng@us.ibm.com X-Lotus-FromDomain: IBMUS To: goldberg@inprise.com cc: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Date: Fri, 4 Dec 1998 15:26:34 -0600 Subject: Re: uses of recursive_tc Content-Disposition: inline Hi, I agree the word "eliminate" is problematic. What I meant by was: 1) Don't support querying a place holder as a normal typecode. Or at least make such a query undefined. 2) Remove the place holder from the final typecode data strucutre. I think we agree that 2) is not prohibited by the current spec, but 1) is. I would like to propose that the wording of the spec be changed to support 1. Otherwise, an implementation that removes the place holder from the final data strucutre will still have to implement extra forwarding code. This is extra burden on the implementation, without adding functionality. Michael Cheng mcheng@us.ibm.com Jon Goldberg on 12/04/98 12:08:40 PM Please respond to goldberg@inprise.com To: Michael Cheng/Austin/IBM cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo Uzcategui/Austin/IBM Subject: Re: uses of recursive_tc Hi- The word "eliminating" is somewhat problematic. The actual TypeCode exists until it is released (or no longer referenced) by the code you listed in your original message. The two questions in my mind are: 1) once you have completed the outer typecode, can you query your recursive typecode as if it a normal TypeCode? 2) once you have completed the outer typecode, will traversing that typecode return the exact same TypeCode object as you created initially? The current wording requires the answer to #1 to be "yes". How you do this is up to you, but that TypeCode is valid. The current wording allows the answer to #2 to be implementation dependent as long as the embedded recursive typecode you created is_equivalent to the one returned when you traverse the outer typecode. This may support your intention of "eliminating"... that the TypeCode is no longer part of the ORB implementation's graph of TypeCode objects. I argue that this is completely hidden from users and there is nothing in the current wording that prohibits it. Is there some aspect of "eliminating" that you are aiming for that I am missing? -Jon mcheng@us.ibm.com wrote: > > Hi Jon, > > My suggestion is aimed at making it possible to eliminate the placeholder > during the resolution of embedded typecode, not to mandate it. > I'm not sure that the current wording allows one to eliminate the > placeholder, > because an interpretation for "[the placeholder] function as a normal > TypeCode" is that one can invoke methods on it explicitly. > > By changing the wording to say that the user may not make calls on the > placeholder typecode, we introduce for the implementor the opportunity > to remove it. Implementations that choose to keep the placeholder in place > in the underlying data structure can still do so. It's just that the > placeholder > is hidden from the user, in that all calls are forwarded to the real > underlying > typecode. > > Michael Cheng > mcheng@us.ibm.com > > Jon Goldberg on 12/03/98 09:56:58 AM > > Please respond to goldberg@inprise.com > > To: Michael Cheng/Austin/IBM > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > Uzcategui/Austin/IBM > Subject: Re: uses of recursive_tc > > Hi Michael- > > Although your suggestion sounds cleaner, eliminating the "placeholder" > typecode > doesn't work in many cases in practice. > > The current wording allows your suggestion (replace the placeholder > with the "real" typecode) or an implementation in which the > placeholder typecode is maintained and just delegates all calls > through to its "real" typecode. Your suggested wording eliminates > the latter possibility and therefore invalidates valid implementations > of typecodes. > > In particular, for languages without garbage collection such as C++, > maintaining the distinct placeholder typecode may be the easiest > way to manage memory. With your suggestion, there is no distinction > between the different types of typecodes and a cycle is created when > you replace the placeholder with a reference to the "real" typecode. > > I'd suggest that this issue be closed with no change to the > specification wording. > > take care, > Jon > > mcheng@us.ibm.com wrote: > > > > Hi, > > > > According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53, > > "Once the recursive TypeCode has been properly embedded in the > > enclosing TypeCode which corresponds to the specified repository > > id, it will function as a normal TypeCode." > > > > Given the following idl: > > > > valuetype v { > > public v m0; > > }; > > > > And the following C++ code to generate the typecode for v: > > > > CORBA::ORB_ptr orb = ...; > > CORBA::TypeCode_ptr tcRecursive = > > orb->create_recursive_tc("IDL:v:1.0"); > > CORBA::ValueMemberSeq v_seq; > > v_seq.length(1); > > v_seq[0].type = tcRecursive; > > ... > > CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v", > > VM_NONE, CORBA::TypeCode::_nil(), > > v_seq); > > > > After tcRecursive has been properly embedded, what does "tcRecursive > > functioning > > like a normal TypeCode" mean? Does it mean that one can call on > > tcRecursive the same > > methods that are available on tcV? For example, will > > > > CORBA::Visibility vis = tcRecursive->member_visibility(0); > > > > work? > > > > I would like to argue that the above should not work, that a recursive > > typecode should > > only be used as a place holder. Afterwards, the real typecode, tcV, is > the > > one > > that the user should use as the normal TypeCode. Otherwise, there is > > unnecessary > > burden placed on the implementor, with no additional benefits. > > > > For the above example, the typecode data structure during construction > > looks like: > > > > v > > | > > member[0] > > | > > recursive_tc(v) (place holder) > > > > The implementation should have the freedom to remove the placeholder as > > follows: > > > > +--> v > > | | > > | member[0] > > | | > > +---+ > > > > But if we were to follow the spec literally, we have to ensure that the > > place holder still > > functions like a real typecode by forwarding all calls to it to the real > > typecode for v: > > +--> v <-----------------recursive_tc_(v) place holder > > | | > > | member[0] > > | | > > +---+ > > > > And we will be burdened with checking for the place holder in all > typecode > > method > > implementations. Therefore, I would like to recommend that the wording > be > > changed, to the > > effect that > > "The recursive TypeCode is only used as a place holder during TypeCode > > construction. > > It may not be used after it has been properly embedded." > > > > Michael Cheng > > mcheng@us.ibm.com Return-Path: Sender: "Jon Goldberg" Date: Fri, 04 Dec 1998 15:02:28 -0800 From: Jon Goldberg Reply-To: goldberg@inprise.com Organization: Visigenic Software, Inc. X-Accept-Language: en To: mcheng@us.ibm.com CC: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Subject: Re: uses of recursive_tc References: <852566D0.007647E9.00@us.ibm.com> Hi Michael- I disagree...I think it does add functionality in that the initially created typecode now functions properly as a full typecode and there is no need for the application code you wrote to go back and re-traverse the "final" typecode. (In addition, making the behavior undefined would be very confusing.) -Jon mcheng@us.ibm.com wrote: > > Hi, > > I agree the word "eliminate" is problematic. What I meant by was: > > 1) Don't support querying a place holder as a normal typecode. Or at > least make such a query undefined. > 2) Remove the place holder from the final typecode data strucutre. > > I think we agree that 2) is not prohibited by the current spec, but > 1) is. > > I would like to propose that the wording of the spec be changed to > support > 1. > Otherwise, an implementation that removes the place holder from the > final > data > strucutre will still have to implement extra forwarding code. This > is extra > burden on the implementation, without adding functionality. > > Michael Cheng > mcheng@us.ibm.com > > Jon Goldberg on 12/04/98 12:08:40 PM > > Please respond to goldberg@inprise.com > > To: Michael Cheng/Austin/IBM > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > Uzcategui/Austin/IBM > Subject: Re: uses of recursive_tc > > Hi- > > The word "eliminating" is somewhat problematic. The actual > TypeCode exists until it is released (or no longer referenced) > by the code you listed in your original message. The two > questions in my mind are: > > 1) once you have completed the outer typecode, can you > query your recursive typecode as if it a normal TypeCode? > > 2) once you have completed the outer typecode, will > traversing that typecode return the exact same TypeCode > object as you created initially? > > The current wording requires the answer to #1 to be > "yes". How you do this is up to you, but that > TypeCode is valid. > > The current wording allows the answer to #2 to be > implementation dependent as long as the embedded > recursive typecode you created is_equivalent to > the one returned when you traverse the outer typecode. > This may support your intention of "eliminating"... > that the TypeCode is no longer part of the ORB > implementation's graph of TypeCode objects. I argue > that this is completely hidden from users and > there is nothing in the current wording that > prohibits it. > > Is there some aspect of "eliminating" that you > are aiming for that I am missing? > > -Jon > Return-Path: From: mcheng@us.ibm.com X-Lotus-FromDomain: IBMUS To: goldberg@inprise.com cc: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Date: Mon, 7 Dec 1998 09:23:10 -0600 Subject: Re: uses of recursive_tc Content-Disposition: inline Hi Jon, Perhaps I should say without adding useful functionality. Since a typecode must be properly embedded into the real typecode, one will always obtain the real tc during typecode construction. As a matter of fact, the real tc is always obtained after the recursive tc, so I'm not sure what you mean by retraversing the "final" typecode. If making it undefined would be confusing, how about making it throw an exception? Michael Cheng mcheng@us.ibm.com Jon Goldberg on 12/04/98 05:02:28 PM Please respond to goldberg@inprise.com To: Michael Cheng/Austin/IBM cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo Uzcategui/Austin/IBM Subject: Re: uses of recursive_tc Hi Michael- I disagree...I think it does add functionality in that the initially created typecode now functions properly as a full typecode and there is no need for the application code you wrote to go back and re-traverse the "final" typecode. (In addition, making the behavior undefined would be very confusing.) -Jon mcheng@us.ibm.com wrote: > > Hi, > > I agree the word "eliminate" is problematic. What I meant by was: > > 1) Don't support querying a place holder as a normal typecode. Or at > least make such a query undefined. > 2) Remove the place holder from the final typecode data strucutre. > > I think we agree that 2) is not prohibited by the current spec, but 1) is. > > I would like to propose that the wording of the spec be changed to support > 1. > Otherwise, an implementation that removes the place holder from the final > data > strucutre will still have to implement extra forwarding code. This is extra > burden on the implementation, without adding functionality. > > Michael Cheng > mcheng@us.ibm.com > > Jon Goldberg on 12/04/98 12:08:40 PM > > Please respond to goldberg@inprise.com > > To: Michael Cheng/Austin/IBM > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > Uzcategui/Austin/IBM > Subject: Re: uses of recursive_tc > > Hi- > > The word "eliminating" is somewhat problematic. The actual > TypeCode exists until it is released (or no longer referenced) > by the code you listed in your original message. The two > questions in my mind are: > > 1) once you have completed the outer typecode, can you > query your recursive typecode as if it a normal TypeCode? > > 2) once you have completed the outer typecode, will > traversing that typecode return the exact same TypeCode > object as you created initially? > > The current wording requires the answer to #1 to be > "yes". How you do this is up to you, but that > TypeCode is valid. > > The current wording allows the answer to #2 to be > implementation dependent as long as the embedded > recursive typecode you created is_equivalent to > the one returned when you traverse the outer typecode. > This may support your intention of "eliminating"... > that the TypeCode is no longer part of the ORB > implementation's graph of TypeCode objects. I argue > that this is completely hidden from users and > there is nothing in the current wording that > prohibits it. > > Is there some aspect of "eliminating" that you > are aiming for that I am missing? > > -Jon > Return-Path: Date: Mon, 07 Dec 1998 10:35:05 -0800 From: "Jon Goldberg" Reply-To: goldberg@inprise.com X-Accept-Language: en To: mcheng@us.ibm.com CC: orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Subject: Re: uses of recursive_tc References: <852566D3.0055058C.00@us.ibm.com> Hi Michael- I think this thread is pretty much running out of steam and it needs to come down to a vote at some point in the RTF (all of this discussion will be preserved in the archive). I would boil down the discussion as: -currently, the spec says the embedded typecode is incomplete when constructed but must function as a real typecode when embedded. This requires implementers to perform some sort of delegation for a recursive tc. -you propose that even once completed, the embedded typecode raise an exception whenever it is programmatically queried. In both scenarios, ORBs must implement a special typecode (the embedded one). In one case to do delegation, in the other to raise exceptions. Both wordings of the spec (the current wording and your proposal) impose a limitation on implementations of recursive typecodes. I don't see any reason to make the embedded typecode unusable if it can just as easily (and with some additional benefits for implementors who are using reference counting) perform the delegation so I prefer that the wording remain unchanged. take care, Jon mcheng@us.ibm.com wrote: > > Hi Jon, > > Perhaps I should say without adding useful functionality. > Since a typecode must be properly embedded into the real typecode, > one will > always > obtain the real tc during typecode construction. As a matter of > fact, the > real tc is always > obtained after the recursive tc, so I'm not sure what you mean by > retraversing > the "final" typecode. > > If making it undefined would be confusing, how about making it throw > an > exception? > > Michael Cheng > mcheng@us.ibm.com > > Jon Goldberg on 12/04/98 05:02:28 PM > > Please respond to goldberg@inprise.com > > To: Michael Cheng/Austin/IBM > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > Uzcategui/Austin/IBM > Subject: Re: uses of recursive_tc > > Hi Michael- > > I disagree...I think it does add functionality in that > the initially created typecode now functions properly > as a full typecode and there is no need for the application > code you wrote to go back and re-traverse the "final" > typecode. (In addition, making the behavior undefined would > be very confusing.) > > -Jon > > mcheng@us.ibm.com wrote: > > > > Hi, > > > > I agree the word "eliminate" is problematic. What I meant by was: > > > > 1) Don't support querying a place holder as a normal typecode. Or > at > > least make such a query undefined. > > 2) Remove the place holder from the final typecode data strucutre. > > > > I think we agree that 2) is not prohibited by the current spec, > but 1) > is. > > > > I would like to propose that the wording of the spec be changed to > support > > 1. > > Otherwise, an implementation that removes the place holder from > the final > > data > > strucutre will still have to implement extra forwarding code. This > is > extra > > burden on the implementation, without adding functionality. > > > > Michael Cheng > > mcheng@us.ibm.com > > > > Jon Goldberg on 12/04/98 12:08:40 PM > > > > Please respond to goldberg@inprise.com > > > > To: Michael Cheng/Austin/IBM > > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > > Uzcategui/Austin/IBM > > Subject: Re: uses of recursive_tc > > > > Hi- > > > > The word "eliminating" is somewhat problematic. The actual > > TypeCode exists until it is released (or no longer referenced) > > by the code you listed in your original message. The two > > questions in my mind are: > > > > 1) once you have completed the outer typecode, can you > > query your recursive typecode as if it a normal TypeCode? > > > > 2) once you have completed the outer typecode, will > > traversing that typecode return the exact same TypeCode > > object as you created initially? > > > > The current wording requires the answer to #1 to be > > "yes". How you do this is up to you, but that > > TypeCode is valid. > > > > The current wording allows the answer to #2 to be > > implementation dependent as long as the embedded > > recursive typecode you created is_equivalent to > > the one returned when you traverse the outer typecode. > > This may support your intention of "eliminating"... > > that the TypeCode is no longer part of the ORB > > implementation's graph of TypeCode objects. I argue > > that this is completely hidden from users and > > there is nothing in the current wording that > > prohibits it. > > > > Is there some aspect of "eliminating" that you > > are aiming for that I am missing? > > > > -Jon > > Return-Path: Sender: jis@fpk.hp.com Date: Tue, 08 Dec 1998 11:26:17 +0000 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: goldberg@inprise.com CC: mcheng@us.ibm.com, orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Subject: Re: uses of recursive_tc References: <852566D3.0055058C.00@us.ibm.com> <366C1FD9.525033AC@inprise.com> I would be happy to place this issue on the scheduled December 11 vote. I am hoping that I will also be able to include a bunch of OBV related issues that Simon has raised in this vote too. So could someone please propose a concise motion that I could include in the vote? Of course if everyone is too busy preparing for the big holidays now, the next available opportunity to place this on a vote will be on January 8th. Let me know how you want to proceed. Thanks, Jishnu. Jon Goldberg wrote: > Hi Michael- > > I think this thread is pretty much running out of steam > and it needs to come down to a vote at some point in the > RTF (all of this discussion will be preserved in the > archive). I would boil down the discussion as: > > -currently, the spec says the embedded typecode is incomplete > when constructed but must function as a real typecode when > embedded. This requires implementers to perform some > sort of delegation for a recursive tc. > > -you propose that even once completed, the embedded typecode > raise an exception whenever it is programmatically queried. > > In both scenarios, ORBs must implement a special typecode > (the embedded one). In one case to do delegation, in the > other to raise exceptions. Both wordings of the spec (the > current wording and your proposal) impose a limitation on > implementations of recursive typecodes. > > I don't see any reason to > make the embedded typecode unusable if it can just as > easily (and with some additional benefits for implementors > who are using reference counting) perform the delegation > so I prefer that the wording remain unchanged. > > take care, > Jon > > mcheng@us.ibm.com wrote: > > > > Hi Jon, > > > > Perhaps I should say without adding useful functionality. > > Since a typecode must be properly embedded into the real typecode, one will > > always > > obtain the real tc during typecode construction. As a matter of fact, the > > real tc is always > > obtained after the recursive tc, so I'm not sure what you mean by > > retraversing > > the "final" typecode. > > > > If making it undefined would be confusing, how about making it throw an > > exception? > > > > Michael Cheng > > mcheng@us.ibm.com > > > > Jon Goldberg on 12/04/98 05:02:28 PM > > > > Please respond to goldberg@inprise.com > > > > To: Michael Cheng/Austin/IBM > > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > > Uzcategui/Austin/IBM > > Subject: Re: uses of recursive_tc > > > > Hi Michael- > > > > I disagree...I think it does add functionality in that > > the initially created typecode now functions properly > > as a full typecode and there is no need for the application > > code you wrote to go back and re-traverse the "final" > > typecode. (In addition, making the behavior undefined would > > be very confusing.) > > > > -Jon > > > > mcheng@us.ibm.com wrote: > > > > > > Hi, > > > > > > I agree the word "eliminate" is problematic. What I meant by was: > > > > > > 1) Don't support querying a place holder as a normal typecode. Or at > > > least make such a query undefined. > > > 2) Remove the place holder from the final typecode data strucutre. > > > > > > I think we agree that 2) is not prohibited by the current spec, but 1) > > is. > > > > > > I would like to propose that the wording of the spec be changed to > > support > > > 1. > > > Otherwise, an implementation that removes the place holder from the final > > > data > > > strucutre will still have to implement extra forwarding code. This is > > extra > > > burden on the implementation, without adding functionality. > > > > > > Michael Cheng > > > mcheng@us.ibm.com > > > > > > Jon Goldberg on 12/04/98 12:08:40 PM > > > > > > Please respond to goldberg@inprise.com > > > > > > To: Michael Cheng/Austin/IBM > > > cc: orb_revision@omg.org, Alex Mcleod/Austin/IBM, Leo > > > Uzcategui/Austin/IBM > > > Subject: Re: uses of recursive_tc > > > > > > Hi- > > > > > > The word "eliminating" is somewhat problematic. The actual > > > TypeCode exists until it is released (or no longer referenced) > > > by the code you listed in your original message. The two > > > questions in my mind are: > > > > > > 1) once you have completed the outer typecode, can you > > > query your recursive typecode as if it a normal TypeCode? > > > > > > 2) once you have completed the outer typecode, will > > > traversing that typecode return the exact same TypeCode > > > object as you created initially? > > > > > > The current wording requires the answer to #1 to be > > > "yes". How you do this is up to you, but that > > > TypeCode is valid. > > > > > > The current wording allows the answer to #2 to be > > > implementation dependent as long as the embedded > > > recursive typecode you created is_equivalent to > > > the one returned when you traverse the outer typecode. > > > This may support your intention of "eliminating"... > > > that the TypeCode is no longer part of the ORB > > > implementation's graph of TypeCode objects. I argue > > > that this is completely hidden from users and > > > there is nothing in the current wording that > > > prohibits it. > > > > > > Is there some aspect of "eliminating" that you > > > are aiming for that I am missing? > > > > > > -Jon > > > Return-Path: Date: Wed, 09 Dec 1998 00:44:20 -0800 From: "Jon Goldberg" Reply-To: goldberg@inprise.com X-Accept-Language: en To: Jishnu Mukerji CC: mcheng@us.ibm.com, orb_revision@omg.org, amcleod@us.ibm.com, leou@us.ibm.com Subject: Re: uses of recursive_tc References: <852566D3.0055058C.00@us.ibm.com> <366C1FD9.525033AC@inprise.com> <366D0CD9.A3933C4A@fpk.hp.com> I propose that this issue be closed with no change for the reasons summarized in my message below. Hopefully that's concise enough of a motion... :) take care, Jon Jishnu Mukerji wrote: > > I would be happy to place this issue on the scheduled December 11 > vote. I am > hoping that I will also be able to include a bunch of OBV related > issues that > Simon has raised in this vote too. So could someone please propose a > concise > motion that I could include in the vote? Of course if everyone is > too busy > preparing for the big holidays now, the next available opportunity > to place this > on a vote will be on January 8th. > > Let me know how you want to proceed. > > Thanks, > > Jishnu. > > Jon Goldberg wrote: > > > Hi Michael- > > > > I think this thread is pretty much running out of steam > > and it needs to come down to a vote at some point in the > > RTF (all of this discussion will be preserved in the > > archive). I would boil down the discussion as: > > > > -currently, the spec says the embedded typecode is incomplete > > when constructed but must function as a real typecode when > > embedded. This requires implementers to perform some > > sort of delegation for a recursive tc. > > > > -you propose that even once completed, the embedded typecode > > raise an exception whenever it is programmatically queried. > > > > In both scenarios, ORBs must implement a special typecode > > (the embedded one). In one case to do delegation, in the > > other to raise exceptions. Both wordings of the spec (the > > current wording and your proposal) impose a limitation on > > implementations of recursive typecodes. > > > > I don't see any reason to > > make the embedded typecode unusable if it can just as > > easily (and with some additional benefits for implementors > > who are using reference counting) perform the delegation > > so I prefer that the wording remain unchanged. > > > > take care, > > Jon > >