Issue 1587: name scoping issue (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In the course of a discussion Philippe Gautron pointed out to me that in ISO-C++, the scope of a class begins with its declaration, and hence a member or type declaration in the class may not introduce the same name as that of the class, exception being constructors of the class. Analogous rules apply to struct and namespace. When this principle is extended to the case insensitivity of IDL a consequence is that interface I { void i(); }; is illegal as is: module M { interface m {....}; }; The basic rule is that the name of the scope, if it has one is implicitly inserted into the scope and hence cannot be reused for other purposes in that scope. Given that IDL has to be mapped to C++ this seems like an eminently reasonable restriction. However, I could not find this explicitly stated anywhere. Do y"all feel this is reasonable? If so, and if it is indeed not mentioned then I think we should add a line or two in 3.13 clarifying this? Resolution: Revised Text: Actions taken: June 26, 1998: received issue March 1, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jis@fpk.hp.com Date: Fri, 26 Jun 1998 12:09:16 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: orb_revision@omg.org Cc: Philippe Gautron Subject: Name scoping again In the course of a discussion Philippe Gautron pointed out to me that in ISO-C++, the scope of a class begins with its declaration, and hence a member or type declaration in the class may not introduce the same name as that of the class, exception being constructors of the class. Analogous rules apply to struct and namespace. When this principle is extended to the case insensitivity of IDL a consequence is that interface I { void i(); }; is illegal as is: module M { interface m {....}; }; The basic rule is that the name of the scope, if it has one is implicitly inserted into the scope and hence cannot be reused for other purposes in that scope. Given that IDL has to be mapped to C++ this seems like an eminently reasonable restriction. However, I could not find this explicitly stated anywhere. Do y'all feel this is reasonable? If so, and if it is indeed not mentioned then I think we should add a line or two in 3.13 clarifying this? Comments? Jishnu. -- Jishnu Mukerji 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: Fri, 26 Jun 1998 18:03:08 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jishnu Mukerji CC: orb_revision@omg.org, Philippe Gautron Subject: Re: Name scoping again References: <3593C7AC.B236B94C@fpk.hp.com> Jishnu Mukerji wrote: > > In the course of a discussion Philippe Gautron pointed out to me > that > in > ISO-C++, the scope of a class begins with its declaration, and hence > a > member or type declaration in the class may not introduce the same > name > as that of the class, exception being constructors of the class. > Analogous rules apply to struct and namespace. When this principle > is > extended to the case insensitivity of IDL a consequence is that > > interface I { > void i(); > }; > > is illegal as is: > > module M { > interface m {....}; > }; > > The basic rule is that the name of the scope, if it has one is > implicitly inserted into the scope and hence cannot be reused for > other > purposes in that scope. Given that IDL has to be mapped to C++ this > seems like an eminently reasonable restriction. However, I could not > find this explicitly stated anywhere. Do y'all feel this is > reasonable? > If so, and if it is indeed not mentioned then I think we should add > a > line or two in 3.13 clarifying this? > > Comments? IDL is not C++ and so need not carry *all* the latter's idiosynchrocies into IDL. (It already has too many.) It doesn't seem natural to me for a single declaration to define a name in both the enclosing scope and in the newly created scope. This seems like something that ought to be dealt with as a C++ mapping issue. For instance in your example, the "duplicate" name in the inner scope could be mapped as _cxx_i or _cxx_m as it would if it was a reserved word. (That is just an off the cuff suggestion - there is probably something better to do.) Return-Path: Sender: jis@fpk.hp.com Date: Fri, 26 Jun 1998 19:04:21 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Paul H Kyzivat Cc: orb_revision@omg.org, Philippe Gautron Subject: Re: Name scoping again References: <3593C7AC.B236B94C@fpk.hp.com> <35941A9C.F5108C1A@noblenet.com> Paul H Kyzivat wrote: > > Jishnu Mukerji wrote: > > > > In the course of a discussion Philippe Gautron pointed out to me > that > > in > > ISO-C++, the scope of a class begins with its declaration, and > hence a > > member or type declaration in the class may not introduce the > same > > name > > as that of the class, exception being constructors of the class. > > Analogous rules apply to struct and namespace. When this principle > is > > extended to the case insensitivity of IDL a consequence is that > > > > interface I { > > void i(); > > }; > > > > is illegal as is: > > > > module M { > > interface m {....}; > > }; > > > > The basic rule is that the name of the scope, if it has one is > > implicitly inserted into the scope and hence cannot be reused for > > other > > purposes in that scope. Given that IDL has to be mapped to C++ > this > > seems like an eminently reasonable restriction. However, I could > not > > find this explicitly stated anywhere. Do y'all feel this is > > reasonable? > > If so, and if it is indeed not mentioned then I think we should > add a > > line or two in 3.13 clarifying this? > > > > Comments? > > IDL is not C++ and so need not carry *all* the latter's > idiosynchrocies > into IDL. (It already has too many.) It doesn't seem natural to me > for a > single declaration to define a name in both the enclosing scope and > in > the newly created scope. So it is merely a matter of taste with you then?:-) > This seems like something that ought to be dealt with as a C++ mapping > issue. For instance in your example, the "duplicate" name in the inner > scope could be mapped as _cxx_i or _cxx_m as it would if it was a > reserved word. (That is just an off the cuff suggestion - there is > probably something better to do.) Paul, It seems to me that we should at least understand why that particular "idiosyncracy" exists in C++ and then if it is unsuitable for IDL not adopt it in IDL. But just to take the position that since it is a C++ idosyncracy it should be rejected in IDL in my opinion is somewhat idiosyncratic:-). This position in general is unreasonable I think because the reason behind a lot of the C++ idiosyncracies are also obtained in Java, and some are even obtained in ANSI C. Those languages are of great importance to many of us, and it is nice to have a simple and understandable mapping to these languages, one aspect of which is absence of special cases. Additionally, the reason that I raised this issue in this form is that when we were working on the Scoping Rules in the last RTF we generally took the position that since scoping issues were thought out very carefully by the ANSI and ISO C++ folks, and since whether you like it or not, the design of IDL is certainly very similar to C++, therefore whenever possible we would use that set of scoping rules as a model for determining what the scoping rules should be for IDL. This is not to say that we should copy everything from C++, but it is certainly reasonable that we should understand fully why C++ did something and then choose not to do it that way. If we so choose we should precisely state what we chose to do instead, so that readers of the spec are not left guessing. So I still think we should discuss this issue and come to a more educated conclusion based on a more in depth analysis of the issue. Now over to the experts - I don't claim to be one of them.:-) I suppose we can wait until after the 4th of July weekend for Steve++ to return.:-) Cheers, Jishnu. -- Jishnu Mukerji 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: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 29 Jun 1998 15:34:28 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: orb_revision@omg.org, Philippe Gautron Subject: Re: Name scoping again On Fri, 26 Jun 1998, Jishnu Mukerji wrote: > In the course of a discussion Philippe Gautron pointed out to me that in > ISO-C++, the scope of a class begins with its declaration, and hence a > member or type declaration in the class may not introduce the same name > as that of the class, exception being constructors of the class. > Analogous rules apply to struct and namespace. No, only to structs and classes, but not namespaces. > When this principle is > extended to the case insensitivity of IDL a consequence is that > > interface I { > void i(); > }; > > is illegal Yes. You can't have anything inside a class with the same name as the class itself, so you can't have an operation with the name of the interface inside an interface. In fact, the name of the interface is already "used up", because it is also a type name: interface chain { chain next(); }; It follows that I can't have an operation/attribute named chain in this interface, nor can I have a typedef to chain, or an enum or exception called chain, etc. > as is: > > module M { > interface m {....}; > }; No, the analogous construct in C++ is not illegal. In C++, the following is perfectly OK: namespace M { class M { }; }; > The basic rule is that the name of the scope, if it has one is > implicitly inserted into the scope and hence cannot be reused for > other > purposes in that scope. Given that IDL has to be mapped to C++ this > seems like an eminently reasonable restriction. However, I could not > find this explicitly stated anywhere. Do y'all feel this is > reasonable? There is a a bit of a problem if we directly adopt the C++ rule. Assume we make the following legal: module M { interface M {}; }; We now have a problem for C++ compilers that don't have namespaces. The mapping would require the above to be mapped to nested classes, but the nested class can't have the same name as its enclosing class. (For compilers that provide namespaces, the above is no problem of course.) So, I think we should go for the strict interpretation and say that both the following are illegal: interface I { void i(); // Illegal, as is void I(); }; module M { module M {}; // Illegal, same name as enclosing module }; Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 29 Jun 1998 15:37:41 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Jishnu Mukerji , orb_revision@omg.org, Philippe Gautron Subject: Re: Name scoping again Content-ID: On Fri, 26 Jun 1998, Paul H Kyzivat wrote: > IDL is not C++ and so need not carry *all* the latter's idiosynchrocies > into IDL. (It already has too many.) It doesn't seem natural to me for a > single declaration to define a name in both the enclosing scope and in > the newly created scope. Using C++ scoping rules has some major advantages. They are both well defined and well understood. > This seems like something that ought to be dealt with as a C++ mapping > issue. For instance in your example, the "duplicate" name in the inner > scope could be mapped as _cxx_i or _cxx_m as it would if it was a > reserved word. (That is just an off the cuff suggestion - there is > probably something better to do.) We could do something like that, but I can't say I like it. Also, we get into yet another round of #include problems with such a mapping: module M { #include "myM.idl" }; If myM.idl also contains a module M, separate compilation becomes impossible, because the enclosing scope changes the mapping of the enclosed scope. Extremely bad news! Of course, you could argue that this is really a #include problem, but I still believe that using something like _cxx_i is a bad move. Better not to allow a named scope to contain something with the same name... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 29 Jun 1998 10:58:40 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jishnu Mukerji CC: orb_revision@omg.org, Philippe Gautron Subject: Re: Name scoping again References: <3593C7AC.B236B94C@fpk.hp.com> <35941A9C.F5108C1A@noblenet.com> <359428F5.96955048@fpk.hp.com> Jishnu Mukerji wrote: > > Paul H Kyzivat wrote: [snip] > > IDL is not C++ and so need not carry *all* the latter's > idiosynchrocies > > into IDL. (It already has too many.) It doesn't seem natural to me > for a > > single declaration to define a name in both the enclosing scope > and > in > > the newly created scope. > > So it is merely a matter of taste with you then?:-) Much of what distinguishes a good language design from a bad one is a matter of taste. > > > This seems like something that ought to be dealt with as a C++ > mapping > > issue. For instance in your example, the "duplicate" name in the > inner > > scope could be mapped as _cxx_i or _cxx_m as it would if it was a > > reserved word. (That is just an off the cuff suggestion - there is > > probably something better to do.) > > Paul, > > It seems to me that we should at least understand why that > particular > "idiosyncracy" exists in C++ and then if it is unsuitable for IDL > not > adopt it in IDL. But just to take the position that since it is a > C++ > idosyncracy it should be rejected in IDL in my opinion is somewhat > idiosyncratic:-). This position in general is unreasonable I think > because the reason behind a lot of the C++ idiosyncracies are also > obtained in Java, and some are even obtained in ANSI C. Those > languages > are of great importance to many of us, and it is nice to have a > simple > and understandable mapping to these languages, one aspect of which > is > absence of special cases. I realize that the present restrictions in IDL are a compromise designed to allow reasonable language mappings in a variety of languages. If there is no other reasonable way to deal with this then I have no problem with making this restriction. My point is that we shouldn't be seeking out problems in one particular language mapping and making changes in IDL to solve them without first considering a language binding solution to the problem. In this case, the effect of the proposed change will be to merely make a particular usage illegal. This is quite an arbitrary thing to do if some other solution is possible. For instance, it this usage remains legal but has an ugly C++ language binding then people can agree to avoid the problem in order to avoid the ugliness while people using languages not affected by the problem can do as they wish. > > Additionally, the reason that I raised this issue in this form is > that > when we were working on the Scoping Rules in the last RTF we > generally > took the position that since scoping issues were thought out very > carefully by the ANSI and ISO C++ folks, and since whether you like > it > or not, the design of IDL is certainly very similar to C++, > therefore > whenever possible we would use that set of scoping rules as a model > for > determining what the scoping rules should be for IDL. This is not to > say > that we should copy everything from C++, but it is certainly > reasonable > that we should understand fully why C++ did something and then > choose > not to do it that way. If we so choose we should precisely state > what > we > chose to do instead, so that readers of the spec are not left > guessing. > > So I still think we should discuss this issue and come to a more > educated conclusion based on a more in depth analysis of the issue. I have no problem with this. > > Now over to the experts - I don't claim to be one of them.:-) I > suppose > we can wait until after the 4th of July weekend for Steve++ to > return.:-) Fine. Michi Henning wrote: [snip] > Using C++ scoping rules has some major advantages. They are both well > defined > and well understood. > > > This seems like something that ought to be dealt with as a C++ > mapping > > issue. For instance in your example, the "duplicate" name in the > inner > > scope could be mapped as _cxx_i or _cxx_m as it would if it was a > > reserved word. (That is just an off the cuff suggestion - there is > > probably something better to do.) > > We could do something like that, but I can't say I like it. Also, we > get into yet another round of #include problems with such a mapping: > > module M { > #include "myM.idl" > }; > > If myM.idl also contains a module M, separate compilation becomes > impossible, > because the enclosing scope changes the mapping of the enclosed scope. > Extremely bad news! > > Of course, you could argue that this is really a #include problem, but > I > still believe that using something like _cxx_i is a bad move. Better > not to allow a named scope to contain something with the same name... By that logic we shouldn't have the _cxx_ language mapping escape at all. Instead, every reserved word of C++ should be a reserved word of IDL. And of course, every reserved word of Java, ADA, Pascal, ... should also be a reserved word of IDL. Seems like folly to me. Philippe Gautron wrote: [snip] > C/C++ are not the only languages "responsible" for idiosyncracies. > These > languages are case-sensitive. We could require IDL to be > case-sensitive > and mappings for non case-sensitive languages to distinguish > conflicting > identifiers by adding some prefix... I agree with this. It is a fine line that needs to be walked to get this right in IDL. One extreme is the least-common-denominator approach: anything that doesn't map well in all languages is illegal. The other extreme is the greatest-common-multiple approach: anything that would be useful in some language mapping is legal. Neither extreme is very acceptable, and neither has been followed. So far, many of the features of C++ have been accepted into IDL even though some of them lead to ugly mappings in other languages, like C or even Java. Some particularly difficult to map restrictions (like case insensitivity) have been added as restrictions. But I haven't seen anybody suggesting that out and inout arguments be removed from IDL because they cause a problem in the Java mapping. I think some care should be taken to avoid having CORBA being criticized as overly biased in favor of C++. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 30 Jun 1998 07:51:44 +1000 (EST) From: Michi Henning To: orb_revision@omg.org Subject: Re: Name scoping again Content-ID: On Mon, 29 Jun 1998, Paul H Kyzivat wrote: > > > This seems like something that ought to be dealt with as a C++ > > mapping > > > issue. For instance in your example, the "duplicate" name in the > > inner > > > scope could be mapped as _cxx_i or _cxx_m as it would if it was > a > > > reserved word. (That is just an off the cuff suggestion - there > is > > > probably something better to do.) > > > > We could do something like that, but I can't say I like it. Also, > we > > get into yet another round of #include problems with such a > mapping: > > > > module M { > > #include "myM.idl" > > }; > > > > If myM.idl also contains a module M, separate compilation becomes > > impossible, > > because the enclosing scope changes the mapping of the enclosed > scope. > > Extremely bad news! > > > > Of course, you could argue that this is really a #include problem, > but > > I > > still believe that using something like _cxx_i is a bad > move. Better > > not to allow a named scope to contain something with the same > name... > > By that logic we shouldn't have the _cxx_ language mapping escape at > all. Instead, every reserved word of C++ should be a reserved word > of > IDL. And of course, every reserved word of Java, ADA, Pascal, > ... should > also be a reserved word of IDL. Seems like folly to me. Paul, fundamentally, I agree with you. However, don't forget that the IDL scoping rules were *never* defined to start with. We are now trying to back-patch the rules. Also, the C++ mapping never dealt with the case where we have module M { module M {}; }; The current mapping simply generates illegal C++ if modules are mapped to classes. My argument is that whatever rules we make now, they can't just gratuitously break existing mappings. In addition, I think the argument I presented about #including a module inside another module is a serious one, because the including file would change the code generation for the included file. As I said, this would make separate compilation impossible. Also, I think that any such context-sensitive mapping would be a very bad move indeed... > [snip] > > C/C++ are not the only languages "responsible" for idiosyncracies. > > These > > languages are case-sensitive. We could require IDL to be > > case-sensitive > > and mappings for non case-sensitive languages to distinguish > > conflicting > > identifiers by adding some prefix... > > I agree with this. It is a fine line that needs to be walked to get > this > right in IDL. One extreme is the least-common-denominator approach: > anything that doesn't map well in all languages is illegal. The > other > extreme is the greatest-common-multiple approach: anything that > would be > useful in some language mapping is legal. Neither extreme is very > acceptable, and neither has been followed. > > So far, many of the features of C++ have been accepted into IDL even > though some of them lead to ugly mappings in other languages, like C > or > even Java. Some particularly difficult to map restrictions (like > case > insensitivity) have been added as restrictions. But I haven't seen > anybody suggesting that out and inout arguments be removed from IDL > because they cause a problem in the Java mapping. > > I think some care should be taken to avoid having CORBA being > criticized > as overly biased in favor of C++. Sure. On the other hand, IDL can't just deny its legacy, for better or worse. IMO, fiddling with the case sensitivity rules now would simply be too disruptive, with comparatively little gain (the case-insensitivity is not something that causes mapping problems but avoids them). Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html