Issue 2275: Sequences of recursive structs/unions (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: If I have a recursive struct or union type and want to pass a sequence of that type to an operation, I am completely stuck if I want to do this with C++. I"m not sure about other mappings, but I expect that Java, Ada, etc. will all suffer from the same problem. Resolution: Revised Text: Actions taken: December 21, 1998: received issue October 30, 2000: closed issue Discussion: End of Annotations:===== >Return-Path: Date: Mon, 21 Dec 1998 09:22:14 +1000 (EST) From: Michi Henning To: issues@omg.org, orb-revision@omg.org Subject: Sequences of recursive structs/unions Organization: Triodia Technologies Hi, the following just came up in comp.object.corba, for what is probably the tenth time... If I have a recursive struct or union type and want to pass a sequence of that type to an operation, I am completely stuck if I want to do this with C++. I'm not sure about other mappings, but I expect that Java, Ada, etc. will all suffer from the same problem. Here is an example: struct Node { long val; sequence children; }; Fine, no problem. Now I want to pass a sequence of nodes to an operation. Because the actual sequence member type is anonymous, the only way to achieve this is to add another typedef: typedef sequence NodeSeq; interface foo { void op(in NodeSeq param); }; The only glitch with the above is that the C++ mapping requires that sequences must be mapped to distinct classes. As a result, the signature for op() expects a const NodeSeq &. Any attempt to pass a children member of a Node structure then fails because that member has a different and unrelated type. We can easily fix this by adding a forward declaration to IDL: struct Node; // Forward declaration typedef sequence NodeSeq; // OK for now struct Node { // Complete forward decl long val; NodeSeq children; // Use named type }; interface foo { void op(in NodeSeq param); }; This completely eliminates the problem because it gets rid of the anonymous member type and uses the same named type for both the member and the parameter. The same mechanism should be provided for unions, which can also be used to create recursive types. To make life easier for compiler writers, I think we need to restrict the mechanism a little. I'd like to start a bit of discussion on this to see what exactly is needed. Here is a stab at defining the semantics of the forward declaration: - Only unions and structs can be forward declared. - If a forward-declared struct or union appears in a definition, the full definition of the struct or union must appear in the same compilation unit, even if the forward-declared struct or union is never used. - A forward-declared struct or union name can only be used to define a sequence type while the struct or union is only forward declared. Other uses of the forward-declared struct or union must be delayed until after the definition of the struct or union. - A sequence type that (recursively) has an element type that is forward declared and whose full definition has not yet been seen can be used (recursively) only as a member or element of its own incomplete struct or union definition. The above rules are designed to keep compilers single-pass. For example, with the above rules, we get: struct Node; typedef sequence NodeSeq; typedef Node NodeArray[10]; // Illegal struct X { NodeSeq ns; // Illegal }; struct Node { long val; NodeSeq children; // OK, type Node being defined }; Forward declarations potentially open the door to mutually recursive structs and unions. The above rules keep that door shut: struct X; // Forward declaration typedef sequence XSeq; struct Y; // Forward declaration typedef sequence YSeq; struct X { YSeq ymembers; // Illegal }; struct Y { XSeq xmembers; // Illegal }; I think it's a good idea to continue to disallow mutually recursive types such as this. Right now, I am not convinced that allowing them would not create nasty problems for language mappings, the TypeCode API, or the on-the-wire representation of TypeCodes. The following, which recurses over two levels would be legal (as is now): struct Outer; // Forward declaration typedef sequence OuterSeq; struct Outer { union Inner switch (short) { case 0: long val; case 1: OuterSeq children; // OK } u; }; So, I think a forward declaration for structs and unions would solve the original problem. I'd like to see some feedback from the compiler implementors as to any potential problems. Also, we may need to tighten up the rules for exactly when it is legal to forward declare something, and in what contexts it is legal to use the incomplete forward-declared type. Comments? Cheers, Michi. Copyright 1998 Michi Henning. All rights reserved. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0800201FCE5D39B41B7D Date: Sun, 20 Dec 1998 23:26:45 PST Subject: Re: Sequences of recursive structs/unions To: michi@triodia.COM cc: orb_revision@omg.org, Mike_Spreitzer.PARC@xerox.com > Forward declarations potentially open the door to mutually recursive structs > and unions. The above rules keep that door shut: > ... > I think it's a good idea to continue to disallow mutually recursive > types such as this. Well, given the knots we can tie with structs declared inside structs, and the forward declarations allowed for "value types", the door's not all that firmly shut as it is. Exactly which kinds of mutual recursion do you think you're forbidding, and why is that useful (given all the kinds that are already, and would be, allowed)? Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0800201FCE5D39B41B7E Date: Sun, 20 Dec 1998 23:49:59 PST Subject: Re: Sequences of recursive structs/unions To: michi@triodia.COM cc: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org In particular, I presume you're not proposing to repeal the existing general restriction that every recusion ("mutual" or not) involve a sequence, "value", or object. So, part of what I'm wondering is: how do you think that would need to be strengthened? Return-Path: Date: Mon, 21 Dec 1998 19:02:55 +1000 (EST) From: Michi Henning To: Mike_Spreitzer.PARC@xerox.com cc: orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions Organization: Triodia Technologies On Sun, 20 Dec 1998 Mike_Spreitzer.PARC@xerox.com wrote: > > Forward declarations potentially open the door to mutually recursive structs > > and unions. The above rules keep that door shut: > > ... > > I think it's a good idea to continue to disallow mutually recursive > > types such as this. > > Well, given the knots we can tie with structs declared inside structs, and the > forward declarations allowed for "value types", the door's not all that firmly > shut as it is. Exactly which kinds of mutual recursion do you think you're > forbidding, and why is that useful (given all the kinds that are already, and > would be, allowed)? I showed an example of that. Right now, you cannot have two structures that mutually contain each other: struct X { sequence yseq; }; struct Y { sequence xseq; }; There is no way to create such a beast at the moment and my suggestion was to keep it that way. Really, all I am after is to eliminate anonymous types from IDL because they are no end of trouble. We've fixed numerous problems relating to these in the past, and frankly, I'm getting sick of it -- let's put the axe through anonymous types once and for all. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Mon, 21 Dec 1998 19:05:16 +1000 (EST) From: Michi Henning To: Mike_Spreitzer.PARC@xerox.com cc: orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions Organization: Triodia Technologies On Sun, 20 Dec 1998 Mike_Spreitzer.PARC@xerox.com wrote: > In particular, I presume you're not proposing to repeal the existing general > restriction that every recusion ("mutual" or not) involve a sequence, "value", > or object. No, I definitely don't want to repeal that restriction. Things are complicated enough as is :-) > So, part of what I'm wondering is: how do you think that would need > to be strengthened? I was simply asking for feedback on the semantics I outlined. There may well be holes in that set of rules because I've forgotten something. To put it differently, I'm looking for peer review, particularly from the IDL compiler writers. (After all, they are the ones who should know best whether the rules as I outlined them are tight enough or not.) Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Mon, 21 Dec 1998 13:54:05 +0000 From: Simon Nash Organization: IBM To: Michi Henning CC: orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions (fwd) References: Michi, Now that we have valuetypes in IDL, which can be thought of as structs with more flexibility and functionality, I don't think we should be adding any more functionality to structs, such as allowing them to be forward declared. Valuetypes can already be forward declared, so I presume that if Node in your example were changed from struct to valuetype, there would be no problem. I would leave structs as is and suggest that users switch to valuetypes if they need this improved functionality. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Return-Path: Date: Tue, 22 Dec 1998 09:02:32 +1000 (EST) From: Michi Henning To: Simon Nash cc: orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions Organization: Triodia Technologies On Mon, 21 Dec 1998, Simon Nash wrote: > Michi, > Now that we have valuetypes in IDL, which can be thought of as > structs > with more flexibility and functionality, I don't think we should be > adding any more functionality to structs, such as allowing them to > be > forward declared. > > Valuetypes can already be forward declared, so I presume that if > Node > in your example were changed from struct to valuetype, there would > be > no problem. > > I would leave structs as is and suggest that users switch to > valuetypes > if they need this improved functionality. Hmmm... I agree, valuetypes can be used for this. However, they are not universally (well, not at all ;-) available at this point. Also, it grates on me that there is a hole in IDL in the way you have to define recursive data structures. It can only be achieved using anonymous data types, which is bad news. There are really two issues here: 1) IDL still permits the use anonymous in some cases. For example: struct x { long a[10]; struct y { long a; short b; } s; union z switch(long) { case 0: string s; } u; sequence ss; fixed<8,2> f; }; I am proposing to get rid of anonymous types once and for all because they are nothing but trouble for the various language mappings. 2) The case I outlined for recursive structs and unions is simply a special case of the above. It is worse than ordinary anonymous types because it cannot be avoided. This leads to unresolvable problems for the C++ mapping (and probably others): there is no way to pass the sequence member of a recursive struct as an operation parameter. So, I see point (2) as a defect, not as functionality to be added. While valuetypes can be used in this case, the problem of anonymous types won't go away. In addition, the problem I describe is real -- a number of people have run into it in the past and asked for help on comp.object.corba. The nasty thing is that you can only tell them that "sorry, there is no solution." I really think we should fix this. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Sun, 3 Jan 1999 12:53:03 PST Sender: Bill Janssen From: Bill Janssen To: Michi Henning , Simon Nash Subject: Re: Sequences of recursive structs/unions (fwd) CC: orb_revision@omg.org References: <367E52FD.79031909@hursley.ibm.com> Excerpts from local.omg: 21-Dec-98 Re: Sequences of recursive .. Simon Nash@hursley.ibm.c (707*) > Now that we have valuetypes in IDL, which can be thought of as structs > with more flexibility and functionality, I don't think we should be > adding any more functionality to structs, such as allowing them to be > forward declared. It's not adding functionality to structs, Simon -- it's fixing a problem with IDL. Asking users to switch to that oddly packaged sack of functionality called a valuetype seems overkill to me -- let them continue to use plain old structs, even if they aren't in Java. Bill Return-Path: To: Michi Henning cc: issues@omg.org, orb-revision@omg.org Subject: Re: Sequences of recursive structs/unions Date: Mon, 04 Jan 1999 16:07:34 +1000 From: Keith Duddy Hi Michi! > typedef sequence NodeSeq; > > interface foo { > void op(in NodeSeq param); > }; > >The only glitch with the above is that the C++ mapping requires that >sequences must be mapped to distinct classes. As a result, the signature >for op() expects a const NodeSeq &. Any attempt to pass a children >member of a Node structure then fails because that member has a different >and unrelated type. > >We can easily fix this by adding a forward declaration to IDL: > > struct Node; // Forward declaration > typedef sequence NodeSeq; // OK for now > > struct Node { // Complete forward decl > long val; > NodeSeq children; // Use named type > }; > > interface foo { > void op(in NodeSeq param); > }; > >This completely eliminates the problem because it gets rid of the anonymous >member type and uses the same named type for both the member and the >parameter. I'd be worried that IDL needs to be written in only one of several legal ways in order to be used from a particular language mapping. Why can't the C++ mapping be augmented to generate the class for the typedef in the second version, so that both styles of IDL can be used with all language mappings. I think adding a forward decl for structs (and/or unions) is a lot of IDL change for a partial solution to a language mapping problem (which can still occur when they are not used). > - A sequence type that (recursively) has an element type that > is forward declared and whose full definition has not yet been > seen can be used (recursively) only as a member or element of its > own incomplete struct or union definition. This sounds sensible - as it makes one style of IDL illegal, and therfore equally unusable in all languages. I'm most worried about having 2 legal IDL styles when only one works for all language mappings. ciao, K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, 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: Mon, 4 Jan 1999 16:14:42 +1000 (EST) From: Michi Henning To: Keith Duddy cc: orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions Organization: Triodia Technologies On Mon, 4 Jan 1999, Keith Duddy wrote: > I'd be worried that IDL needs to be written in only one of several > legal ways in order to be used from a particular language > mapping. Why > can't the C++ mapping be augmented to generate the class for the > typedef in the second version, so that both styles of IDL can be > used > with all language mappings. I think adding a forward decl for > structs > (and/or unions) is a lot of IDL change for a partial solution to a > language mapping problem (which can still occur when they are not > used). Well, the problem of anonymous types hits all language mappings, not just C++. You could come up with a way to generate a standardized name for anonymous types but you would have to do it for all mappings, which seems worse than the solution I suggest. > > - A sequence type that (recursively) has an element type that > > is forward declared and whose full definition has not yet > been > > seen can be used (recursively) only as a member or element > of its > > own incomplete struct or union definition. > > This sounds sensible - as it makes one style of IDL illegal, and > therfore equally unusable in all languages. I'm most worried about > having 2 legal IDL styles when only one works for all language > mappings. I'm not exactly sure what you mean by two legal IDL styles. Can you post an example? My proposal suggests to make anonymous IDL types illegal once and for all, in all cases. That would put a definite end to the problems as far as I can see. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Date: Tue, 05 Jan 1999 19:16:38 +0000 From: Simon Nash Organization: IBM To: Bill Janssen CC: Michi Henning , orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions (fwd) References: <367E52FD.79031909@hursley.ibm.com> Bill, My point has nothing to do with what's in Java. It's that IDL has recently added a feature that provides the functionality needed. Given that, it's not clear to me that we should add complexity by providing another way to do the same thing. Simon Bill Janssen wrote: > > Excerpts from local.omg: 21-Dec-98 Re: Sequences of recursive > .. Simon > Nash@hursley.ibm.c (707*) > > > Now that we have valuetypes in IDL, which can be thought of as > structs > > with more flexibility and functionality, I don't think we should > be > > adding any more functionality to structs, such as allowing them to > be > > forward declared. > > It's not adding functionality to structs, Simon -- it's fixing a > problem > with IDL. Asking users to switch to that oddly packaged sack of > functionality called a valuetype seems overkill to me -- let them > continue to use plain old structs, even if they aren't in Java. > > Bill -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 05 Jan 1999 18:42:15 -0500 To: Simon Nash From: Steve Vinoski Subject: Re: Sequences of recursive structs/unions (fwd) Cc: Bill Janssen , Michi Henning , orb_revision@omg.org References: <367E52FD.79031909@hursley.ibm.com> At 07:16 PM 1/5/99 +0000, Simon Nash wrote: >Bill, >My point has nothing to do with what's in Java. It's that IDL has >recently added a feature that provides the functionality needed. >Given that, it's not clear to me that we should add complexity by >providing another way to do the same thing. Simon, you're totally missing the point. 1) Michi wants to eliminate anonymous types from IDL. They have been causing trouble for years, and they provide no benefit. Please tell us how valuetypes solve all the problems with anonymous types. 2) Because the valuetype specification is so bulky, complex, and full of holes, I predict it will be years before anyone really implements it correctly. Many agree with me. I personally will not use it in my IDL. Do we really want to push people who are trying to get real work done to use such a complicated and poorly-specified type? --steve Return-Path: Date: Wed, 06 Jan 1999 11:43:19 +0000 From: Simon Nash Organization: IBM To: Steve Vinoski CC: Bill Janssen , Michi Henning , orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions (fwd) References: <367E52FD.79031909@hursley.ibm.com> <199901052343.SAA12192@boston.iona.ie> Steve, Actually, Michi's proposal in the email that started this thread was not to eliminate anonymous types from IDL. It was to add forward declarations for structs and unions, with a number of proposed rules for when this would be legal. This was the added complexity that I don't think is justified. If the proposal is now to remove anonymous types and not add forward declarations, I am much more sympathetic towards that. Regarding your second point, IBM is implementing support for valuetypes in both its Java and C++ ORBs. These will be available this year. So I think it is entirely appropriate to suggest that people use these when they need functionality that is provided by this core CORBA feature. Simon Steve Vinoski wrote: > > At 07:16 PM 1/5/99 +0000, Simon Nash wrote: > >Bill, > >My point has nothing to do with what's in Java. It's that IDL has > >recently added a feature that provides the functionality needed. > >Given that, it's not clear to me that we should add complexity by > >providing another way to do the same thing. > > Simon, you're totally missing the point. > > 1) Michi wants to eliminate anonymous types from IDL. They have been > causing trouble for years, and they provide no benefit. Please tell > us how > valuetypes solve all the problems with anonymous types. > > 2) Because the valuetype specification is so bulky, complex, and > full of > holes, I predict it will be years before anyone really implements it > correctly. Many agree with me. I personally will not use it in my > IDL. Do > we really want to push people who are trying to get real work done > to use > such a complicated and poorly-specified type? > > --steve -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Wed, 06 Jan 1999 11:30:43 -0500 To: Simon Nash From: Steve Vinoski Subject: Re: Sequences of recursive structs/unions (fwd) Cc: orb_revision@omg.org References: <367E52FD.79031909@hursley.ibm.com> <199901052343.SAA12192@boston.iona.ie> At 11:43 AM 1/6/99 +0000, Simon Nash wrote: >Steve, >Actually, Michi's proposal in the email that started this thread was >not to eliminate anonymous types from IDL. It was to add forward >declarations for structs and unions, with a number of proposed rules >for when this would be legal. Which is part of an overall effort to eliminate the need for anonymous types. >If the proposal is now to remove anonymous types and not add >forward declarations, I am much more sympathetic towards that. I don't believe we can remove anonymous types without adding forward declarations. How else could you declare a recursive type? >Regarding your second point, IBM is implementing support for >valuetypes in both its Java and C++ ORBs. These will be available >this year. So I think it is entirely appropriate to suggest that >people use these when they need functionality that is provided by >this core CORBA feature. You didn't read my message very carefully. IONA is also implementing valuetypes, and I'm sure Inprise and all other ORB suppliers are as well. That wasn't my point. My point is that valuetypes are so complex and the specification so full of holes that I predict it will literally be years before we see implementations that conform correctly to the specification and are interoperable. After all, it's now 1999 -- four years after IIOP was introduced -- and real-world CORBA users still suffer interoperability problems. Sadly, the marshaling complexities introduced by valuetypes increase the overall complexity of IIOP by orders of magnitude. As I said in my previous message, and as I have stated in various publications, I recommend that anyone who wants their systems to actually work avoid the use of valuetypes. I make this suggestion not to be difficult, but only to offer an educated suggestion from a practical perspective, a suggestion that might keep someone from going down the wrong path with their CORBA implementation by banking on the poorly specified, immature valuetype technology. I can't speak for them, but I believe Michi's suggested fixes, and Bill's commentary regarding those proposed fixes, were also made from the perspective of folks trying to evolve their systems in a practical manner. --steve Return-Path: Date: Thu, 7 Jan 1999 06:31:15 +1000 (EST) From: Michi Henning To: Simon Nash cc: Steve Vinoski , Bill Janssen , orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions (fwd) Organization: Triodia Technologies On Wed, 6 Jan 1999, Simon Nash wrote: > Steve, > Actually, Michi's proposal in the email that started this thread was > not to eliminate anonymous types from IDL. It was to add forward > declarations for structs and unions, with a number of proposed rules > for when this would be legal. > > This was the added complexity that I don't think is justified. > > If the proposal is now to remove anonymous types and not add > forward declarations, I am much more sympathetic towards that. It's really both. I want to get rid of anonymous types. Because recursive sequence types are anonymous, they are included. The only way I can see to get rid of the anonymous type in this case is to add a forward declaration. > Regarding your second point, IBM is implementing support for > valuetypes in both its Java and C++ ORBs. These will be available > this year. So I think it is entirely appropriate to suggest that > people use these when they need functionality that is provided by > this core CORBA feature. I don't think I agree. Recursive types are in use already and plagued by the anonymous type issue already. I want to see a fix for the bug we have for ordinary anonymous sequence types. Whether then people use OBV or not for the recursive types is up to them. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Return-Path: Sender: jis@fpk.hp.com Date: Wed, 06 Jan 1999 16:15:38 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Michi Henning CC: Simon Nash , Steve Vinoski , Bill Janssen , orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions (fwd) References: Michi Henning wrote: > > I don't think I agree. Recursive types are in use already and > plagued > by the anonymous type issue already. I want to see a fix for the bug > we have for ordinary anonymous sequence types. Whether then people > use > OBV or not for the recursive types is up to them. I tend to agree with michi on this one. Problems with recursive types for structs should be fixed for structs, without pulling in the OBV stuff in to do so. Just my PHO (Personal humble Opinion). So I thought we already had an issue on this in the Core RTF list. How about a proposed resolution? 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. Return-Path: Date: Thu, 7 Jan 1999 07:13:22 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Simon Nash , Steve Vinoski , Bill Janssen , orb_revision@omg.org Subject: Re: Sequences of recursive structs/unions (fwd) Organization: Triodia Technologies On Wed, 6 Jan 1999, Jishnu Mukerji wrote: > So I thought we already had an issue on this in the Core RTF list. How > about a proposed resolution? I'll write something up but give me a few days please. Are you going to do one of your usual bug scrubs? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 4 Nov 1999 13:49:19 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com Reply-To: Core Revision Task Force To: Core Revision Task Force Subject: Proposal for issues 1729, 2034, and 2275 Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: a"7e9/eL!!nO'e9WFI!! Hi, I've forwarded a new version of Chapter 3 with change bars to Jishnu. Jishnu, can you please announce the location of the PDF separately -- I don't want to get slammed again for sending largish documents to the mailing list. (Hi Jeff! :-) This new version eliminates anonymous types from IDL. I have verified that the grammar changes do not introduce conflicts. Summary of changes: 1) Strings and wide strings Bounded strings are no longer legal as a type specifier without a typedef. For example: struct Address { wstring<20> name; // Illegal string<10> country; // Illegal }; The new rules force definition using a typedef: typedef wstring<20> NameType; typedef string<10> CountryType; struct Address { NameType name; CountryType country; }; The changes consider bounded strings and wide strings as template types, but consider unbounded strings and wide strings as base types. 2) Fixed-point types are no longer legal as a type specifier without a typedef. For example: interface Account { readonly attribute fixed<20,2> balance; // Illegal }; The new rules force definition using a typedef: interface typedef fixed<20,2> BalanceType; readonly attribute BalanceType balance; }; 3) Template types are no longer legal as member or const types. For example: union u switch(long) { case 0: sequence seq_val; // Illegal case 1: fixed<3,1> fixed_val; // Illegal case 2: string<12> string_val; // Illegal case 3: wstring<20> wstring_val; // Illegal }; const string<12> GREETING = "Hello world!"; These now all require a typedef: typedef sequence LongSeq; typedef fixed<3,1> ShortFixed; typedef string<12> StringType; typedef string<20> WStringType; union u switch(long) { case 0: LongSeq seq_val; case 1: ShortFixed fixed_val; case 2: StringType string_val; case 3: WStringType wstring_val; }; const StringType GREETING = "Hello world!"; 4) Sequence element types can no longer be complex. For example: sequence< sequence > LongSeqSeq; // Illegal sequence< string<10> > > BStringSeq; // Illegal The sequence element type must be a base type or a scoped name: typedef sequence LongSeq; typedef sequence LongSeqSeq; typedef string<10> ShortString; typedef sequence BStringSeq; typedef sequence StringSeq; // OK 5) State members can no longer have complex type. For example: valuetype Foo { private sequence list_of_long; // Illegal };' As for structures, unions, exceptions, attributes, etc, a typedef must be used: valuetype Foo { typedef sequence LongSeq; private LongSeq list_of_long; }; 6) Complex declarators for arrays have been removed. For example: struct foo { long member[10]; // Illegal }; You need to use a typedef to name the array type: typedef long Long10[10]; struct foo { Long10 member; }; 7) Recursive types are now possible only via a forward declaration for a struct or union. For example: typedef struct foo; // Forward declaration typedef sequence FooSeq; // OK, foo forward declared struct foo { // Provide definition long l; FooSeq chain; // Recurse }; The spec now also clarifies that multi-level recursion is possible via both structures and unions. It also adds a bunch of rules to make it impossible to abuse forward-declared structures, unions, and sequences containing forward-declared structures or unions. Cheers, Michi. PS: A note on change bars: throughout the document, snippets of the grammar that appears on pages 3-12 to 3-18 are repeated. These snippets carry the production number. Because I added a few new productions, the numbering has shifted down. The grammar extracts throughout the document do not reflect the new numbering. (It appears that these snippets should be FrameMaker cross references into the main grammer, but for some reason they are not and maintain their own number sequence, so I've left updating the production numbering throughout the body of the document as an exercise for the editor.) -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <38213168.92F4ADF0@floorboard.com> Date: Wed, 03 Nov 1999 23:10:32 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Core Revision Task Force Subject: Re: Proposal for issues 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: IKRd9HT)e9?RX!!"Q+e9 Michi Henning wrote: > > Hi, > > I've forwarded a new version of Chapter 3 with change bars to > Jishnu. > Jishnu, can you please announce the location of the PDF separately > -- > I don't want to get slammed again for sending largish documents to > the mailing list. (Hi Jeff! :-) > > This new version eliminates anonymous types from IDL. I have > verified that > the grammar changes do not introduce conflicts. > > Summary of changes: > > 1) Strings and wide strings > > Bounded strings are no longer legal as a type specifier > without > a typedef. For example: ... > 2) Fixed-point types are no longer legal as a type specifier > without > a typedef. ... > 3) Template types are no longer legal as member or const > types. ... > 4) Sequence element types can no longer be complex. For > example: ... > 5) State members can no longer have complex type. For > example: ... > 6) Complex declarators for arrays have been removed. For > example: ... > 7) Recursive types are now possible only via a forward > declaration > for a struct or union. I agree with change #7, in particular since it doesn't break existing IDL to add forward declarations of struct & union. All of the other changes do break existing IDL, and at this time I have to oppose the change unless you can demonstrate a convincing rational why they are needed. Can you give real life examples in the language mappings that show why the grammar needs to be changed so much? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'Core Revision Task Force'" Subject: RE: Proposal for issues 1729, 2034, and 2275 Date: Thu, 4 Nov 1999 10:40:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Z9$e9)eN!!IJ;e97bi!! Maybe I should wait to read the book rather than commenting on the abstract, but I have a question about one point: > 6) Complex declarators for arrays have been removed. > For example: > > struct foo { > long member[10]; // Illegal > }; > > You need to use a typedef to name the array type: > > typedef long Long10[10]; > > struct foo { > Long10 member; > }; Have you prevented the one-step declaration of multidimensioned arrays: typedef long Matrix[10][10]; That would be annoying. I need to read the book before commenting further. Sender: jis@fpk.hp.com Message-ID: <3821A999.3143CAB6@fpk.hp.com> Date: Thu, 04 Nov 1999 10:43:21 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Core Revision Task Force Subject: Re: Proposal for issues 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $=&e9-27e9IA2e9[Afd9 Michi Henning says: > I've forwarded a new version of Chapter 3 with change bars to > Jishnu. > Jishnu, can you please announce the location of the PDF separately > -- > I don't want to get slammed again for sending largish documents to > the mailing list. (Hi Jeff! :-) Thanks Michi, the PDF file will be at URL: http://www.omg.org/pub/orbrev/drafts/3_idlsyn-anonymoustypes.pdf before the end of the day (Thursday 4 Nov.) Core RTF voting members, you need to give careful consideration to this proposal and decide first of all whether this is an appropriate thing for an RTF to do. I would like to hear your opinions on this matter first. Meanwhile you can of course look at the details and discuss revisions to the proposal too. > PS: A note on change bars: throughout the document, snippets of the grammar > that appears on pages 3-12 to 3-18 are repeated. These snippets carry > the production number. Because I added a few new productions, the > numbering has shifted down. The grammar extracts throughout the document > do not reflect the new numbering. (It appears that these snippets > should be FrameMaker cross references into the main grammer, but for > some reason they are not and maintain their own number sequence, so I've > left updating the production numbering throughout the body of the > document as an exercise for the editor.) It is an artifact of Frame that cross references do not seem to carry the tabs in them. Without the tabs the grammar lines do not align correctly at the target point. If anyone knows how to get cross references to carry tabs, I will gladly make the change Michi suggest. Cheers, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 5 Nov 1999 06:34:16 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Paul Kyzivat cc: "'Core Revision Task Force'" Subject: RE: Proposal for issues 1729, 2034, and 2275 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA91401A6@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1J(e9mLEe9Pcpd9E8l!! On Thu, 4 Nov 1999, Paul Kyzivat wrote: > Have you prevented the one-step declaration of multidimensioned arrays: > > typedef long Matrix[10][10]; > > That would be annoying. No, that works as before. It's simply that you can't put an array dimension at the end of a structure/union/exception/state member anymore. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 5 Nov 1999 10:47:50 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: Proposal for issues 1729, 2034, and 2275 In-Reply-To: <38213168.92F4ADF0@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: [RKe9o=R!!GTRd9c I agree with change #7, in particular since it doesn't break existing > IDL to add forward declarations of struct & union. Actually it does; the words I added to the spec make the following illegal: struct foo { long l; sequence chain; }; You have to use a forward decl and a typedef to express this under the proposal. > All of the other > changes do break existing IDL, and at this time I have to oppose the > change unless you can demonstrate a convincing rational why they are > needed. Can you give real life examples in the language mappings > that > show why the grammar needs to be changed so much? The following examples are currently legal IDL. All of them generate unusable C++ APIs: typedef sequence< sequence > StringTable; typedef sequence StringArray[20]; union u switch(long) { case 0: StringTable table; case 1: sequence numbers; case 2: string names[20]; case 3: StringArray vector; }; With all of these, the resulting anonymous types make it impossible to: - declare a variable that is a row of a string table - initialize the numbers member - pass the names member to a function - pass an element of vector to a function The above is just one example of the general problem of having things like structure, union, exception, or state members of a type that is anonymous. Similar arguments apply to things like constant definitions. If the type of a constant is anonymous, I can't assign it to a variable, cannot pass the constant to an operation, etc. The following recursive type also generates unusable C++: struct foo { long l; sequence chain; }; typedef sequence FooChain; interface I { void op(in FooChain param); }; It is impossible in C++ to call op() with the chain member of the struct because two different types are generated for FooChain and sequence. Depending on the language mapping, fixed-point types and bounded strings can create the same problems: struct foo { fixed<20,3> val1; string<15> val2; }; For C++, these aren't a problem because the C++ mapping uses loose typing for fixed-point and bounded string types. However, that need not be the case in general. Both fixed-point and bounded string types are parameterized types and so really define a whole family of types. If a language mapping uses strong typing for these, the same problems appear as for other anonymous types. Anonymous types have bitten us many times over the years. We made a half-hearted attempt to get rid of them when we made them illegal as attribute and parameter types. But that only solved a subset of the problems that were cause by anonymous types. The remainder are still with us and cause the same problems over and over again in all language mappings that use strong typing. (The issue is not confined to C++ but applies to Java, Ada, etc.) We discussed dealing with these problems as part of the C++ mapping. However, the rules required to solve the problems are worse than the cure. They result in ugly and artificial type names, can make the mapping dependent on the order of definitions in the IDL, etc. What is worse, solving the problem for C++ doesn't solve it for any of the other mappings. A related problem is the issue of repository IDs. For anonymous types, the repository ID is the empty string. Makes it kind of hard to look for that type in the IFR unless I navigate to it via the definition of the enclosing type. And, of course, anonymous types don't have a name either, so TypeCode::name returns an empty string for these too. Yet another one: struct x { octet word[4]; }; How do I extract the value of the word member into a variable from an Any? the _forany helper functions can't be generated because the type is anonymous... I realize that the changes I suggest are not backward compatible. On the other hand, fixing code that relies on them to conform to the new syntax is trivial, and the constructs that would be affected are not commonly used. Jon, you yourself raised quite a few issues about anonymous types in the past. We all know that they are trouble. I went through my e-mail archives and found many dozens of e-mails where I answered questions from users because they got themselves into trouble with anonymous types. Why insist on retaining anonymous types in IDL when the are generally regarded as bad style, generate unusable APIs, and makes life more complicated than necessary? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <38233EC4.73A7C31F@floorboard.com> Date: Fri, 05 Nov 1999 12:32:04 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: Proposal for issues 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A65!!YWp!!T-^d9boH!! Michi Henning wrote: > > On Wed, 3 Nov 1999, Jonathan Biggar wrote: > > > I agree with change #7, in particular since it doesn't break > existing > > IDL to add forward declarations of struct & union. > > Actually it does; the words I added to the spec make the following > illegal: > > struct foo { > long l; > sequence chain; > }; > > You have to use a forward decl and a typedef to express this under > the > proposal. What I meant was adding the forward declaration, not removing the anonymous sequence. > The following examples are currently legal IDL. All of them generate > unusable C++ APIs: > > typedef sequence< sequence > StringTable; > typedef sequence StringArray[20]; > > union u switch(long) { > case 0: > StringTable table; > case 1: > sequence numbers; > case 2: > string names[20]; > case 3: > StringArray vector; > }; > > With all of these, the resulting anonymous types make it impossible > to: > > - declare a variable that is a row of a string table > > - initialize the numbers member Not true, since the union will contain a _numbers_seq typedef. > - pass the names member to a function Not true, since the union will contain a _slice typedef which can be portably used to reconstruct the type of the names member. > - pass an element of vector to a function This can also be done via the _slice typedef. > The above is just one example of the general problem of having things > like structure, union, exception, or state members of a type that is > anonymous. Similar arguments apply to things like constant definitions. > If the type of a constant is anonymous, I can't assign it to a variable, > cannot pass the constant to an operation, etc. For constant definitions, this only applies to Fixed, and there is a generic Fixed class for C++ that solves this problem. > The following recursive type also generates unusable C++: > > struct foo { > long l; > sequence chain; > }; > typedef sequence FooChain; > > interface I { > void op(in FooChain param); > }; > > It is impossible in C++ to call op() with the chain member of the > struct > because two different types are generated for FooChain and > sequence. > > Depending on the language mapping, fixed-point types and bounded > strings > can create the same problems: > > struct foo { > fixed<20,3> val1; > string<15> val2; > }; > > For C++, these aren't a problem because the C++ mapping uses loose > typing > for fixed-point and bounded string types. However, that need not be > the > case in general. Both fixed-point and bounded string types are > parameterized > types and so really define a whole family of types. If a language > mapping > uses strong typing for these, the same problems appear as for other > anonymous > types. I'm not aware that there is a problem with the other strong typed mappings. I believe in Ada, these are mapped to well defined templated (discriminated is the term in Ada), which can be used by a programmer at will. In Java, since sequences & arrays are mapped to variable length arrays, there also is no problem. > Anonymous types have bitten us many times over the years. We made a > half-hearted attempt to get rid of them when we made them illegal as > attribute and parameter types. But that only solved a subset of the > problems that were cause by anonymous types. The remainder are still > with > us and cause the same problems over and over again in all language > mappings > that use strong typing. (The issue is not confined to C++ but > applies to > Java, Ada, etc.) > > We discussed dealing with these problems as part of the C++ > mapping. However, > the rules required to solve the problems are worse than the > cure. They > result in ugly and artificial type names, can make the mapping > dependent > on the order of definitions in the IDL, etc. What is worse, solving > the > problem for C++ doesn't solve it for any of the other mappings. The problems really only appear in C++, and the problem boils down to a single thing. Sequences and Fixed in C++ are not required to be defined as templates with a well defined name. Perhaps it is time to bite the bullet and fix that problem in the C++ mapping, rather than making a major perturbation to the core. > A related problem is the issue of repository IDs. For anonymous types, > the repository ID is the empty string. Makes it kind of hard to look > for that type in the IFR unless I navigate to it via the definition of > the enclosing type. And, of course, anonymous types don't have a name > either, so TypeCode::name returns an empty string for these too. This is a red herring, since anonymous types have no need for repository IDs or TypeCode name strings since they don't appear in as an IDL formal parameter anywhere. > Yet another one: > > struct x { > octet word[4]; > }; > > How do I extract the value of the word member into a variable from > an Any? > the _forany helper functions can't be generated because the type is > anonymous... > > I realize that the changes I suggest are not backward compatible. On > the > other hand, fixing code that relies on them to conform to the new > syntax is > trivial, and the constructs that would be affected are not commonly > used. > > Jon, you yourself raised quite a few issues about anonymous types in > the past. > We all know that they are trouble. I went through my e-mail archives > and > found many dozens of e-mails where I answered questions from users > because > they got themselves into trouble with anonymous types. Why insist on > retaining anonymous types in IDL when the are generally regarded as > bad > style, generate unusable APIs, and makes life more complicated than > necessary? Here is my argument. OMG is already finding it hard to keep the language mappings up to date with the core. More changes like this, in particular ones that are driven by the "needs" of a single language mapping just exacerbates the issue. I'm all for changes that get rid of the necessity for anonymous types, but not for disallowing existing IDL which people are managing to use right now. For that reason, I support adding forward declarations for struct & union, but none of the rest. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 8 Dec 1999 14:36:09 +1000 (EST) From: Michi Henning To: Core Revision Task Force Subject: 2nd try for 1729, 2034, and 2275 Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: O_h!!Ecgd9$YPe9+&kd9 OK, about to come is try #2 for anonymous types. I've sent the modified IDL chapter to Jishnu. Jishnu, can you put it up for review again and announce the URL please? To summarize, everything is exactly as before, except that: 1) I've added a forward declaration for structures and unions to make it possible to avoid anonymous members. 2) I've added a section that deprecates (but does not remove) anonymous types, together with a list of examples to illustrate what may become illegal one day. The changes to the spec are in three places: Page 3-15 and 3-40 contain the change to the grammar to permit forward declarations for structures and unions. Page 3-42 and 3-43 contain new text to illustrate use of forward declarations. I've also fleshed out the examples quite a bit to make it clear that recursion can span multiple levels and severely restricted the use of forward-declared structures and unions so we don't shoot ourselves in the foot because of use of incomplete types. Pages 4-47 to 4-49 contain new text that deprecates anonymous types, together with a number of examples. You will find change bars in a lot of other places. However, those aren't real changes but are caused by updates to cross references because of page spills. As before, the production numbers for the grammar snippets throughout the document are out because of the lack of proper cross referencing into the main grammar. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@floorboard.com Message-ID: <38503FA8.3F5338FB@floorboard.com> Date: Thu, 09 Dec 1999 15:47:52 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f$c!!O]Y!!V6Q!!D1$e9 Michi Henning wrote: > about to come is try #2 for anonymous types. I've sent the modified > IDL > chapter to Jishnu. Jishnu, can you put it up for review again and > announce > the URL please? To summarize, everything is exactly as before, > except that: > > 1) I've added a forward declaration for structures and > unions > to make it possible to avoid anonymous members. > > 2) I've added a section that deprecates (but does not > remove) > anonymous types, together with a list of examples to > illustrate > what may become illegal one day. > > The changes to the spec are in three places: > > Page 3-15 and 3-40 > > contain the change to the grammar to permit forward > declarations for structures and unions. > > Page 3-42 and 3-43 > > contain new text to illustrate use of forward > declarations. > I've also fleshed out the examples quite a bit to > make > it clear that recursion can span multiple levels and > severely restricted the use of forward-declared > structures > and unions so we don't shoot ourselves in the foot > because > of use of incomplete types. > > Pages 4-47 to 4-49 > > contain new text that deprecates anonymous types, > together > with a number of examples. I've reviewed the changes and they look ok. I'm a little concerned that we are going overboard in deprecated ALL usages of anonymous types. In particular: 1. multidimensional arrays 2. fixed 3. bounded strings Could the proponents of deprecation (is that just you Michi?) please explain why these 3 particular usages cause problems with language mappings? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 10 Dec 1999 10:01:30 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <38503FA8.3F5338FB@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HQ1e9]BAe9XbOe9@2J!! On Thu, 9 Dec 1999, Jonathan Biggar wrote: > 1. multidimensional arrays > 2. fixed > 3. bounded strings > > Could the proponents of deprecation (is that just you Michi?) please > explain why these 3 particular usages cause problems with language > mappings? Multidimensional arrays cause problems if, for example, you want to insert a row of the array into an any, or pass it as a parameter, or some such. Because the row type is anonymous, the name of the helper function for Any insertion/extraction is undefined, as is the type of the parameter. I decided to deal with fixed and bounded strings in the same way simply because they are not single types, but parameterized types that define entire families of concrete types. For something like the C++ mapping, where fixed and bounded strings are dealt with generically, this doesn't cause any problems. However, if some language mapping decides to map these to separate types in the programming language, we end up with the same anonymous type problems as for all the other user-defined types. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@floorboard.com Message-ID: <38518C6B.552165D1@floorboard.com> Date: Fri, 10 Dec 1999 15:27:39 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: e(ld9mA?e9&Rd!!K3*!! Michi Henning wrote: > > On Thu, 9 Dec 1999, Jonathan Biggar wrote: > > > 1. multidimensional arrays > > 2. fixed > > 3. bounded strings > > > > Could the proponents of deprecation (is that just you Michi?) > please > > explain why these 3 particular usages cause problems with language > > mappings? > > Multidimensional arrays cause problems if, for example, you want to > insert a row of the array into an any, or pass it as a parameter, or > some > such. Because the row type is anonymous, the name of the helper > function > for Any insertion/extraction is undefined, as is the type of the > parameter. Generally not, since all of the CORBA language mappings that I am familiar with do not allocate a different type for a single dimensional array and the row of a multidimensional array (assumeing the length is the same). Why are you trying to insert an anonymous array type into an Any? You will have to use DynAny anyway if you are manufacturing one up out of whole cloth. > I decided to deal with fixed and bounded strings in the same way simply > because they are not single types, but parameterized types that define > entire families of concrete types. For something like the C++ mapping, > where fixed and bounded strings are dealt with generically, this doesn't > cause any problems. However, if some language mapping decides to map > these to separate types in the programming language, we end up with > the same anonymous type problems as for all the other user-defined types. Again, I'd like to see explicit examples of existing language bindings (or ones likely to be standardized in the near future) that treat fixed or bounded strings in a way that cause this problem. In general, your fears appear to be not founded on facts, but what you are afraid might happen. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sun, 12 Dec 1999 10:49:30 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <38518C6B.552165D1@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Ro3e9*kZ!!o8_!!hC*!! On Fri, 10 Dec 1999, Jonathan Biggar wrote: > > Multidimensional arrays cause problems if, for example, you want to > > insert a row of the array into an any, or pass it as a parameter, or some > > such. Because the row type is anonymous, the name of the helper function > > for Any insertion/extraction is undefined, as is the type of the parameter. > > Generally not, since all of the CORBA language mappings that I am > familiar with do not allocate a different type for a single dimensional > array and the row of a multidimensional array (assumeing the length is > the same). Jon, for an IDL type typedef long MyArray[10][20] no operator<<= or operator>>= is even generated for inserting or extracting a row of the array. > Why are you trying to insert an anonymous array type into an Any? You > will have to use DynAny anyway if you are manufacturing one up out of > whole cloth. I may want to insert a row of this array, for whatever reason. Anonymous array types make it impossible to that portably and I may not find out until later, after the application is deployed. Besides, if you have no problem with the above IDL, you should have a problem with this either: typedef sequence MyArray[10]; In either case, the element type of the array is anonymous and causes problems. > > I decided to deal with fixed and bounded strings in the same way simply > > because they are not single types, but parameterized types that define > > entire families of concrete types. For something like the C++ mapping, > > where fixed and bounded strings are dealt with generically, this doesn't > > cause any problems. However, if some language mapping decides to map > > these to separate types in the programming language, we end up with > > the same anonymous type problems as for all the other user-defined types. > > Again, I'd like to see explicit examples of existing language bindings > (or ones likely to be standardized in the near future) that treat fixed > or bounded strings in a way that cause this problem. It wasn't all that long ago that C++ did in fact have fixed types as distinct template types. In addition, if we were to do a new C++ mapping today, I would almost certainly map bounded strings to a template type that uses the bound as a template parameter. (The only reason we didn't do this initially was that templates weren't available on most compilers.) In COBOL, fixed maps to PICTURE definitions. I don't know enough about COBOL to know what the type compatibility rules are for such things though. > In general, your fears appear to be not founded on facts, but what you > are afraid might happen. Well, the original template mapping for C++ fixed is a fact. It is also a fact that I cannot insert a row of the array above portably into an Any. (Please, don't tell me that I have no right to do so or some such -- it is well possible for an application to use 2-D arrays and only discover the need to put rows of such an array into an any much later.) As I said earlier, multi-dimensional arrays by definition create anonymous types unless the inner dimensions are named. Similarly, bounded strings and fixed create anonymous types because each defines a whole family of distinct types. The goal was to eliminate anonymous types from IDL because the cause no end of trouble, which is what the current proposal does. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <385303E3.F764909@floorboard.com> Date: Sat, 11 Dec 1999 18:09:39 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: S9I!!SB!e9d_^!!iGK!! Michi Henning wrote: > > On Fri, 10 Dec 1999, Jonathan Biggar wrote: > > > > Multidimensional arrays cause problems if, for example, you want > to > > > insert a row of the array into an any, or pass it as a > parameter, or some > > > such. Because the row type is anonymous, the name of the helper > function > > > for Any insertion/extraction is undefined, as is the type of the > parameter. > > > > Generally not, since all of the CORBA language mappings that I am > > familiar with do not allocate a different type for a single > dimensional > > array and the row of a multidimensional array (assumeing the > length is > > the same). > > Jon, for an IDL type > > typedef long MyArray[10][20] > > no operator<<= or operator>>= is even generated for inserting or > extracting > a row of the array. So? If the programmer needs to deal with rows of the array, then he'll use a typedef to get what he needs. I just don't see the need to insert or extract a component of a multidimensional array in an any. > > Why are you trying to insert an anonymous array type into an Any? You > > will have to use DynAny anyway if you are manufacturing one up out of > > whole cloth. > > I may want to insert a row of this array, for whatever reason. Anonymous > array types make it impossible to that portably and I may not find out > until later, after the application is deployed. But if you want to do that, just use typedef. Let me make a counter argument. Requiring the programmer to use typedef to define each dimension of an array when he doesn't need it means his IDL is larger, the translated code is larger, and his application is larger. If the typedef is not necessary, this gives the programmer complete control over the tradeoff of expressiveness vs code size. > Besides, if you have no problem with the above IDL, you should have > a problem with this either: > > typedef sequence MyArray[10]; I wasn't arguing about that one. The parts I don't like are deprecating multidimensional arrays, and direct use of bounded strings & fixed. > In either case, the element type of the array is anonymous and causes > problems. > > > > I decided to deal with fixed and bounded strings in the same way simply > > > because they are not single types, but parameterized types that define > > > entire families of concrete types. For something like the C++ mapping, > > > where fixed and bounded strings are dealt with generically, this doesn't > > > cause any problems. However, if some language mapping decides to map > > > these to separate types in the programming language, we end up with > > > the same anonymous type problems as for all the other user-defined types. > > > > Again, I'd like to see explicit examples of existing language bindings > > (or ones likely to be standardized in the near future) that treat fixed > > or bounded strings in a way that cause this problem. > > It wasn't all that long ago that C++ did in fact have fixed types as > distinct template types. In addition, if we were to do a new C++ mapping > today, I would almost certainly map bounded strings to a template type > that uses the bound as a template parameter. (The only reason we didn't > do this initially was that templates weren't available on most compilers.) > > In COBOL, fixed maps to PICTURE definitions. I don't know enough about > COBOL to know what the type compatibility rules are for such things though. > > > In general, your fears appear to be not founded on facts, but what you > > are afraid might happen. > > Well, the original template mapping for C++ fixed is a fact. It is also > a fact that I cannot insert a row of the array above portably into an Any. > (Please, don't tell me that I have no right to do so or some such -- it > is well possible for an application to use 2-D arrays and only discover > the need to put rows of such an array into an any much later.) So, the programmer goes back and adds the IDL typedef later. Since any insertion & extraction as well as DynAny uses TypeCode::equivalent, it won't break anything. > As I said earlier, multi-dimensional arrays by definition create anonymous > types unless the inner dimensions are named. Similarly, bounded strings > and fixed create anonymous types because each defines a whole family > of distinct types. The goal was to eliminate anonymous types from IDL because > the cause no end of trouble, which is what the current proposal does. But multi-dimensional arrays are a standard staple of programming, and everyone is used to using them. I still don't see the need to make them illegal and require everyone to bulk up their IDL. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sun, 12 Dec 1999 20:40:26 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <385303E3.F764909@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: h;md96E>e9(-?e9c+!e9 On Sat, 11 Dec 1999, Jonathan Biggar wrote: > But if you want to do that, just use typedef. Let me make a counter > argument. Requiring the programmer to use typedef to define each > dimension of an array when he doesn't need it means his IDL is > larger, > the translated code is larger, and his application is larger. If > the > typedef is not necessary, this gives the programmer complete control > over the tradeoff of expressiveness vs code size. People keep running into these problems without even being aware of them. > > Besides, if you have no problem with the above IDL, you should have > > a problem with this either: > > > > typedef sequence MyArray[10]; > > I wasn't arguing about that one. The parts I don't like are deprecating > multidimensional arrays, and direct use of bounded strings & fixed. But the two examples are the same. In either case, the element type of the array is anonymous. Whether the element is a sequence or another array is beside the point. If anonymous types really don't do any harm as you suggest, then I would suggest that we rush back and make them legal again for return values and parameter types... > > Well, the original template mapping for C++ fixed is a fact. It is also > > a fact that I cannot insert a row of the array above portably into an Any. > > (Please, don't tell me that I have no right to do so or some such -- it > > is well possible for an application to use 2-D arrays and only discover > > the need to put rows of such an array into an any much later.) > > So, the programmer goes back and adds the IDL typedef later. Since any > insertion & extraction as well as DynAny uses TypeCode::equivalent, it > won't break anything. No, it will break things. For example, it may require repopulating the IFR for deployed clients. > But multi-dimensional arrays are a standard staple of programming, and > everyone is used to using them. I still don't see the need to make > them illegal and require everyone to bulk up their IDL. I'm not suggesting to make multi-dimensional arrays illegal. I'm suggesting to make anonymous element types illegal. Whether the array is single- or multi-dimensional is beside the point. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <385456B4.CD9A2800@floorboard.com> Date: Sun, 12 Dec 1999 18:15:16 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m-ed9F\G!!_g8!!Eil!! Michi Henning wrote: > > > typedef sequence MyArray[10]; > > > > I wasn't arguing about that one. The parts I don't like are > deprecating > > multidimensional arrays, and direct use of bounded strings & > fixed. > > But the two examples are the same. In either case, the element type > of the > array is anonymous. Whether the element is a sequence or another > array is > beside the point. Sure, in the most technical point of view, they are the same, but there is a practical difference. For: typedef long MyArray[10][10]; the anonymous array type is well defined and easy to declare in any of the mapped langugages. > If anonymous types really don't do any harm as you suggest, then I would > suggest that we rush back and make them legal again for return values and > parameter types... Michi, that's not my argument and you know it. I am expressing concern over only three specific anonymous type situations, not all of them. > > > Well, the original template mapping for C++ fixed is a fact. It is also > > > a fact that I cannot insert a row of the array above portably into an Any. > > > (Please, don't tell me that I have no right to do so or some such -- it > > > is well possible for an application to use 2-D arrays and only discover > > > the need to put rows of such an array into an any much later.) > > > > So, the programmer goes back and adds the IDL typedef later. Since any > > insertion & extraction as well as DynAny uses TypeCode::equivalent, it > > won't break anything. > > No, it will break things. For example, it may require repopulating the IFR > for deployed clients. No, it dosn't break clients. Try this: // Original IDL typedef long MyArray[10][10]; // New IDL typedef long MyArray[10][10]; typedef long MyArray_Row[10]; The original definition is unchanged, and the new one is now available. Since Any insertion & extraction (including DynAny) uses TypeCode::equivalent, there won't be any problems. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: giddiv@gamma Message-Id: In-Reply-To: <385456B4.CD9A2800@floorboard.com> References: Mime-Version: 1.0 Date: Sun, 12 Dec 1999 23:20:03 -0500 To: Jonathan Biggar From: Victor Giddings Subject: Re: 2nd try for 1729, 2034, and 2275 Cc: Michi Henning , Core Revision Task Force Content-Type: text/plain; charset="us-ascii" X-UIDL: 2W:e9C,cd9n~Sd9`)d!! At 6:15 PM -0800 12/12/99, Jonathan Biggar wrote: >Michi Henning wrote: >> > > typedef sequence MyArray[10]; >> > >> > I wasn't arguing about that one. The parts I don't like are deprecating >> > multidimensional arrays, and direct use of bounded strings & fixed. >> >> But the two examples are the same. In either case, the element type of the >> array is anonymous. Whether the element is a sequence or another array is >> beside the point. > >Sure, in the most technical point of view, they are the same, but there >is a practical difference. > >For: > > typedef long MyArray[10][10]; > >the anonymous array type is well defined and easy to declare in any of >the mapped langugages. Actually I have to disagree. These are not the same type at all. IDL arrays are fixed sized, while the "first" MyArray is not. It makes perfect sense to add another set of 10 longs to the sequence, it does not make any sense for the array. Different semantics, different types. However, I too don't understand the deprecation of multi-dimensional arrays. They are well defined in the mathematical sense. I also don't understand the assumption that multi-dimensional arrays are vectors of vectors, unless it is C++ myopia. There is nothing special about a "row" except that certain languages choose to store them contiguously. Thus, the example put forward of inserting a row into an any seems to me to be a language-specific problem. If we were to adopt a FORTRAN mapping, should all languages be obligated to generate typedefs for the column type so the FORTRAN user can insert a column into an any? What about all the other partitions of the array? Suppose I want to apply a 3x3 convolution to the matrix? Let's keep multi-dimensional arrays. Victor Giddings victor.giddings@ois.com Senior Product Engineer Objective Interface Systems 703-295-6500 1892 Preston White Drive Fax: 703-295-6501 Reston, VA 22091-5448 Date: Mon, 13 Dec 1999 14:38:57 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <385456B4.CD9A2800@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: oEmd9(n2!!=T0!!MU;!! On Sun, 12 Dec 1999, Jonathan Biggar wrote: > > If anonymous types really don't do any harm as you suggest, then I would > > suggest that we rush back and make them legal again for return values and > > parameter types... > > Michi, that's not my argument and you know it. I am expressing concern > over only three specific anonymous type situations, not all of them. Sorry, you are right, of course. Let's say we are even now ;-) > No, it dosn't break clients. Try this: > > // Original IDL > > typedef long MyArray[10][10]; > > // New IDL > typedef long MyArray[10][10]; > typedef long MyArray_Row[10]; > > The original definition is unchanged, and the new one is now > available. > Since Any insertion & extraction (including DynAny) uses > TypeCode::equivalent, there won't be any problems. Does this really work in all cases? I'm not so sure. There is no obligation on the mapping to pick a compatible type for the two row types. (In practice it will -- however, I think that's at least in part due to weak array concept in C++. For other languages with stricter typing, that trick may not work.) Most certainly, it doesn't work for sequences in C++ because each sequence type results in a different and unrelated C++ type. Again, this goes to show that, just because C++ can handle certain anonymous types but not others, this doesn't mean that the same thing will hold for other languages. Here's another one: struct X { string member[10]; }; The type of the array is completely undefined in this case. I can't pass the member portably to a function or insert it into any, etc. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <3854A122.8110BAED@floorboard.com> Date: Sun, 12 Dec 1999 23:32:50 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: AI Again, this goes to show that, just because C++ can handle certain > anonymous > types but not others, this doesn't mean that the same thing will > hold > for other languages. > > Here's another one: > > struct X { > string member[10]; > }; > > The type of the array is completely undefined in this case. I can't > pass > the member portably to a function or insert it into any, etc. Once again, if a programmer needs the name of the type, then he can have one in IDL. Forcing me to write this as: typedef string X_Member[10]; struct X { X_member member; }; when I don't ever need to use member except inside the struct is forcing me to accept the additional baggage of the mapping that I don't need. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 13 Dec 1999 17:42:04 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <3854A122.8110BAED@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: M~\!!HB8e9X:o!!2kOe9 On Sun, 12 Dec 1999, Jonathan Biggar wrote: > > Here's another one: > > > > struct X { > > string member[10]; > > }; > > > > The type of the array is completely undefined in this case. I > can't pass > > the member portably to a function or insert it into any, etc. > > Once again, if a programmer needs the name of the type, then he can > have > one in IDL. > Forcing me to write this as: > > typedef string X_Member[10]; > > struct X { > X_member member; > }; > > when I don't ever need to use member except inside the struct is > forcing > me to accept the additional baggage of the mapping that I don't > need. Yes. On the other hand, people write the IDL first and then change their mind later. I've answered many questions about this in the newsgroup and elsewhere. Basically, I see *nothing* desirable about the first style. It doesn't buy me anything, it doesn't cost any less, etc. The second style (the one you show) is clean, doesn't cost any extra, and keeps people out of trouble down the track. So, why not use it? Remember, we'd not be ruling such definitions out for now, we'd be deprecating them. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <3854A5E6.8C38E142@floorboard.com> Date: Sun, 12 Dec 1999 23:53:10 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %c;e9=>Ae9'j(!!F'/e9 Michi Henning wrote: > > Once again, if a programmer needs the name of the type, then he > can have > > one in IDL. > > Forcing me to write this as: > > > > typedef string X_Member[10]; > > > > struct X { > > X_member member; > > }; > > > > when I don't ever need to use member except inside the struct is > forcing > > me to accept the additional baggage of the mapping that I don't > need. > > Yes. On the other hand, people write the IDL first and then change > their > mind later. I've answered many questions about this in the newsgroup > and > elsewhere. > > Basically, I see *nothing* desirable about the first style. It > doesn't buy > me anything, it doesn't cost any less, etc. The second style (the > one you > show) is clean, doesn't cost any extra, and keeps people out of > trouble > down the track. So, why not use it? Remember, we'd not be ruling > such > definitions out for now, we'd be deprecating them. It does cost you something. It costs, at minimum, 2 class definitions, 6 function definitions (array operations & any inserter & extraction) and 1 typecode constant that the IDL compiler must generate and link into your application. This isn't counting any additional internal stuff that the ORB needs to handle the type correctly. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 13 Dec 1999 18:03:43 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <3854A5E6.8C38E142@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: V~L!!:k"e9`[4e9G\)!! On Sun, 12 Dec 1999, Jonathan Biggar wrote: > > Basically, I see *nothing* desirable about the first style. It doesn't buy > > me anything, it doesn't cost any less, etc. The second style (the one you > > show) is clean, doesn't cost any extra, and keeps people out of trouble > > down the track. So, why not use it? Remember, we'd not be ruling such > > definitions out for now, we'd be deprecating them. > > It does cost you something. It costs, at minimum, 2 class definitions, > 6 function definitions (array operations & any inserter & extraction) > and 1 typecode constant that the IDL compiler must generate and link > into your application. This isn't counting any additional internal > stuff that the ORB needs to handle the type correctly. True, I forgot about that. Still, I think it's a price worth paying. OK. If everyone disagrees with the current proposal, I'll rewrite it yet one more time. But in that case, I'd like precise instructions as to what people want. (I'm getting sick of rewriting this thing ;-) So, you and Victor want to keep multi-dimensional arrays. Fine. You also want to permit array members, a'la: struct X { string member[10]; }; However, you don't want sequence members, like this? struct X { sequence member; }; What about typedef sequence MyType[10]; ??? What about fixed an bounded string types? I *am* concerned about bounded strings. Ideally, they'd be mapped to C++ template types and a future revision of the C++ mapping might do just that. So, are anonymous bounded strings in or out? Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Michi Henning cc: Jonathan Biggar , Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: Your message of "Mon, 13 Dec 1999 00:03:43 PST." Date: Tue, 14 Dec 1999 11:44:32 PST From: Bill Janssen Message-Id: <99Dec14.114437pst."3587"@watson.parc.xerox.com> Content-Type: text X-UIDL: (NUd9m_`d9EEjd9+cD!! > OK. If everyone disagrees with the current proposal, I'll rewrite it yet > one more time. But in that case, I'd like precise instructions as to > what people want. (I'm getting sick of rewriting this thing ;-) I think I'd be OK, but not happy, with multi-dimensional arrays, but not with anything else. Bill To: Jonathan Biggar cc: Michi Henning , Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: Your message of "Sun, 12 Dec 1999 23:32:50 PST." <3854A122.8110BAED@floorboard.com> Date: Tue, 14 Dec 1999 11:42:48 PST From: Bill Janssen Message-Id: <99Dec14.114258pst."3587"@watson.parc.xerox.com> Content-Type: text X-UIDL: 13e!!FZUd9-TIe9I3U!! > Once again, if a programmer needs the name of the type, then he can have > one in IDL. Unfortunately, Jon, the programmer often doesn't get to write the IDL. He or she has to cope with IDL defined by others. This is particularly true in standards-oriented communities, or in large corporations. I've run across too many problems over the years dealing with anonymous types to feel really comfortable with any use of them, even in the various restricted cases you suggest. Bill Sender: jbiggar@floorboard.com Message-ID: <3856AF7C.13C4BD2@floorboard.com> Date: Tue, 14 Dec 1999 12:58:36 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: SGm!!KiYd97+He9Ad"e9 Michi Henning wrote: > OK. If everyone disagrees with the current proposal, I'll rewrite it > yet > one more time. But in that case, I'd like precise instructions as to > what people want. (I'm getting sick of rewriting this thing ;-) Well, at this point only a vocal minority. But we are loud. :-) > So, you and Victor want to keep multi-dimensional arrays. Fine. You also > want to permit array members, a'la: > > struct X { > string member[10]; > }; I think it was a mistake in the C++ mapping not to name the string and object reference member types. We ought to require it, and since existing ORBs can just use a typedef, it shouldn't break anything. Although for compromise, I would be willing to deprecate unnamed arrays as structure members as well. > However, you don't want sequence members, like this? > > struct X { > sequence member; > }; > > What about > > typedef sequence MyType[10]; ??? Nope, don't want that, since the sequence maps to an unnamed type. > What about fixed an bounded string types? I *am* concerned about bounded > strings. Ideally, they'd be mapped to C++ template types and a future > revision of the C++ mapping might do just that. So, are anonymous > bounded strings in or out? In interest in compromise, I'd be willing to drop the bounded strings & fixed if we just kept multidimensional arrays as a direct typedef. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: Jonathan Biggar cc: Michi Henning , Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: Your message of "Tue, 14 Dec 1999 13:45:12 PST." <3856BA68.9CFE9FFE@floorboard.com> Date: Tue, 14 Dec 1999 14:52:10 PST From: Bill Janssen Message-Id: <99Dec14.145213pst."3587"@watson.parc.xerox.com> Content-Type: text X-UIDL: NU1e9CIZd9kUL!!A]&e9 When we were doing ILU's ISL, which doesn't allow anonymous types, we thought about this a bit. It basically comes down to either (1) the ISL writer defines the name of the type, or (2) the stub generator defines the name of the type, or (3) the programming language defines the name of the type (if any). We decided to make all type names explicit in the ISL, so that users of the interface wouldn't have to figure out what the extra layers had done about it. I think that's still a good guide, though it's more of a user cognitive argument than a programming language technology argument. Bill Date: Wed, 15 Dec 1999 07:12:57 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <3856AF7C.13C4BD2@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HC9!!'@Td9liUd9"Xad9 On Tue, 14 Dec 1999, Jonathan Biggar wrote: > > What about fixed an bounded string types? I *am* concerned about bounded > > strings. Ideally, they'd be mapped to C++ template types and a future > > revision of the C++ mapping might do just that. So, are anonymous > > bounded strings in or out? > > In interest in compromise, I'd be willing to drop the bounded strings & > fixed if we just kept multidimensional arrays as a direct typedef. Hah, Jon is getting soft in his old days! :-) Jon, one final question. This is not to be argumentative but to make sure we are not missing something. We all agree that struct X { sequence member; }; causes problems. That's because the sequence maps to a class without a name, so I can't talk about the class. The same problem arises for sequence< sequence > whether it is typedef'd or not. Here, the element type is anonymous and I end up with the problem that I can't declare variables to set and get the elements of the outer sequence. Now, for arrays, the trend seems to be to accept things such as typedef long MyArray[10][20]; Why is this so? Note that this is exactly analogous to typedef sequence< sequence< long > > MySequence; In both cases, element types are anonymous. Why is the first seen to be acceptable? I have a suspicion that it is seen as acceptable because people think in terms of the C++ language mapping, not in terms of arbitrary language mappings. In C++, we map arrays to real C++ arrays, so the multi-dimensional array doesn't cause a problem. In contrast, sequences are mapped to classes, so anonymous element types do cause problems. Why do we map to real arrays in C++? I think the answer goes back to the insistence (way back when) that binary compatibility between C and C++ mappings must be possible. Without that requirement, any sane person would map arrays to classes with proper bounds checking. In addition, a mapping to classes would fix a large number of holes in the type system (for example, for any insertion and extraction of arrays, as well as passing of arrays as parameters). So, the big question: if you assume for the moment that the C++ mapping were to use a mapping of arrays to classes, would you still consider anonymous array elements to be benign? I suspect that most people would no longer consider them benign. If that is indeed the case, we still should deprecate anonymous array elements. That's because if we don't, every language mapping that wants to map arrays into a proper type (and not the half-hearted kind of array type we have in C++) will run into the anonymous type problem. Or, to put it differently, allowing multi-D arrays without a name for the type of each dimension makes it impossible to map arrays to a strong type concept in the target language without suffering anonymous type problems. I would urge you to consider the above before casting a final vote. I'm genuinely concerned about this. If my analysis doesn't hang together, fine, shoot it down :-) But please, at least consider it and see whether the idea has some merit. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@floorboard.com Message-ID: <3856BA68.9CFE9FFE@floorboard.com> Date: Tue, 14 Dec 1999 13:45:12 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gK@e93,(!!!a&e9]lYd9 Michi Henning wrote: > Now, for arrays, the trend seems to be to accept things such as > > typedef long MyArray[10][20]; > > Why is this so? Note that this is exactly analogous to > > typedef sequence< sequence< long > > MySequence; > > In both cases, element types are anonymous. > > Why is the first seen to be acceptable? I have a suspicion that it > is > seen as acceptable because people think in terms of the C++ language > mapping, not in terms of arbitrary language mappings. I'm not only thinking C++. As far as I know, all of the current language mappings define the "unnamed" row type of a multidimensional array using a well formed language construct that allows the programmer to declare a variable of the row type and pass it as a parameter. > In C++, we map arrays to real C++ arrays, so the multi-dimensional array > doesn't cause a problem. In contrast, sequences are mapped to classes, > so anonymous element types do cause problems. > > Why do we map to real arrays in C++? I think the answer goes back to the > insistence (way back when) that binary compatibility between C and C++ > mappings must be possible. Without that requirement, any sane person > would map arrays to classes with proper bounds checking. In addition, > a mapping to classes would fix a large number of holes in the type system > (for example, for any insertion and extraction of arrays, as well as > passing of arrays as parameters). > > So, the big question: if you assume for the moment that the C++ mapping > were to use a mapping of arrays to classes, would you still consider > anonymous array elements to be benign? I suspect that most people would > no longer consider them benign. If that is indeed the case, we still > should deprecate anonymous array elements. That's because if we don't, > every language mapping that wants to map arrays into a proper type > (and not the half-hearted kind of array type we have in C++) will run > into the anonymous type problem. > > Or, to put it differently, allowing multi-D arrays without a name for > the type of each dimension makes it impossible to map arrays to a strong > type concept in the target language without suffering anonymous type problems. If we have the luxury of redefining the C++ mapping, then we also have the luxury of giving the "anonymous" array row types well defined names in the C++ mapping. They would almost certainly be a template type, something like this: template < class T, CORBA::ULong len > IDL_Array; Voila! No problem! > I would urge you to consider the above before casting a final vote. I'm > genuinely concerned about this. If my analysis doesn't hang together, fine, > shoot it down :-) But please, at least consider it and see whether the > idea has some merit. Bang! Bang! :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: giddiv@gamma Message-Id: In-Reply-To: References: <3856AF7C.13C4BD2@floorboard.com> Mime-Version: 1.0 Date: Tue, 14 Dec 1999 23:17:36 -0500 To: Michi Henning From: Victor Giddings Subject: Re: 2nd try for 1729, 2034, and 2275 Cc: Core Revision Task Force Content-Type: text/plain; charset="us-ascii" X-UIDL: aTA!!BEn!!68Rd918O!! At 7:12 AM +1000 12/15/99, Michi Henning wrote: >On Tue, 14 Dec 1999, Jonathan Biggar wrote: > >> > What about fixed an bounded string types? I *am* concerned about bounded >> > strings. Ideally, they'd be mapped to C++ template types and a future >> > revision of the C++ mapping might do just that. So, are anonymous >> > bounded strings in or out? >> >> In interest in compromise, I'd be willing to drop the bounded strings & >> fixed if we just kept multidimensional arrays as a direct typedef. > >Hah, Jon is getting soft in his old days! :-) > >Jon, one final question. This is not to be argumentative but to make sure >we are not missing something. > >We all agree that > > struct X { > sequence member; > }; > >causes problems. That's because the sequence maps to a class without a name, >so I can't talk about the class. The same problem arises for > > sequence< sequence > > >whether it is typedef'd or not. Here, the element type is anonymous >and I end up with the problem that I can't declare variables to set >and get the elements of the outer sequence. > >Now, for arrays, the trend seems to be to accept things such as > > typedef long MyArray[10][20]; > >Why is this so? Note that this is exactly analogous to > > typedef sequence< sequence< long > > MySequence; > >In both cases, element types are anonymous. Michi, I'm trying not to be argumentative too, but I don't understand the statement that they are exactly analogous. MyArray always has 200 elements of type long, while MySequence has any (non-negative) number of elements. To me, this is an important part of the "contract" between the client and the server, and thus leads to different types. (It also tends to lead to different mappings, the array can be static, while the nested sequence cannot be.) Whether the "element types" are anonymous is a somewhat different question. We could (maybe we have had ;-) long arguments about whether the intended definition of MyArray is array of length of (array of length 20) or simply 10x20 matrix. I think, perhaps a more interesting question is whether a user must declare one of these "anonymous components" in order to construct an instance of the declared type. For MyArray, I think the answer is no in all the current languages. For MySequence, I think the answer is yes in all the current languages. > >Why is the first seen to be acceptable? I have a suspicion that it is >seen as acceptable because people think in terms of the C++ language >mapping, not in terms of arbitrary language mappings. > >In C++, we map arrays to real C++ arrays, so the multi-dimensional array >doesn't cause a problem. In contrast, sequences are mapped to classes, >so anonymous element types do cause problems. > >Why do we map to real arrays in C++? I think the answer goes back to the >insistence (way back when) that binary compatibility between C and C++ >mappings must be possible. Without that requirement, any sane person >would map arrays to classes with proper bounds checking. In addition, >a mapping to classes would fix a large number of holes in the type system >(for example, for any insertion and extraction of arrays, as well as >passing of arrays as parameters). > >So, the big question: if you assume for the moment that the C++ mapping >were to use a mapping of arrays to classes, would you still consider >anonymous array elements to be benign? I suspect that most people would >no longer consider them benign. If that is indeed the case, we still >should deprecate anonymous array elements. That's because if we don't, >every language mapping that wants to map arrays into a proper type >(and not the half-hearted kind of array type we have in C++) will run >into the anonymous type problem. > >Or, to put it differently, allowing multi-D arrays without a name for >the type of each dimension makes it impossible to map arrays to a strong >type concept in the target language without suffering anonymous type problems. > >I would urge you to consider the above before casting a final vote. I'm >genuinely concerned about this. If my analysis doesn't hang together, fine, >shoot it down :-) But please, at least consider it and see whether the >idea has some merit. > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Victor Giddings victor.giddings@ois.com Senior Product Engineer Objective Interface Systems 703-295-6500 1892 Preston White Drive Fax: 703-295-6501 Reston, VA 22091-5448 From: Paul Kyzivat To: "'Michi Henning'" , Jonathan Biggar Cc: Core Revision Task Force Subject: RE: 2nd try for 1729, 2034, and 2275 Date: Wed, 15 Dec 1999 17:46:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: PTbd9Zl*e90CC!!)4a!! > Without that requirement, any sane person > would map arrays to classes with proper bounds checking. In > addition, > a mapping to classes would fix a large number of holes in the > type system (for example, for any insertion and extraction of > arrays, > as well as passing of arrays as parameters). Yes/no. Any sane person would map arrays to template classes with proper bounds checking. This has somewhat different effects on the type system. Date: Fri, 17 Dec 1999 09:22:49 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Core Revision Task Force Subject: Re: 2nd try for 1729, 2034, and 2275 In-Reply-To: <3856BA68.9CFE9FFE@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %4*!!&7M!!]L?e9j8md9 On Tue, 14 Dec 1999, Jonathan Biggar wrote: > template < class T, CORBA::ULong len > IDL_Array; > > Voila! No problem! > > Bang! Bang! :-) ARHHGGGG... --- THUMP. ;-) OK. I've forwarded the updated version to Jishnu. It's exactly the same as before, with one change in the section about deprecation of anonymous types. I've removed the multi-dimensional array example. I believe that this captures the consensus of the discussion that we had. Feel free to disagree or object. However, if you do, I have to warn you that then someone else can keep editing this chapter -- I'm getting bloody sick of making changes myself ;-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html