Issue 1087: IDl "module" construct - IDL files (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: It appears that the IDL concept of a module is tightly bound to the storage of IDL statements in files. In other words, it does not seem to be possible to distribute IDL statements in the same logical module across multiple files. Consequently, few people use the concept, and name collisions occur sooner or later when trying to integrate systems that have not been developed by only one group. Resolution: Revised Text: Actions taken: March 20, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Thu, 19 Mar 1998 16:02:54 -0800 X-Sender: ernst@postal.isi.com To: issues@omg.org From: Johannes Ernst Subject: IDL "module" construct - IDL files It appears that the IDL concept of a module is tightly bound to the storage of IDL statements in files. In other words, it does not seem to be possible to distribute IDL statements in the same logical module across multiple files. Consequently, few people use the concept, and name collisions occur sooner or later when trying to integrate systems that have not been developed by only one group. Instead, I propose to 1) either explicitely allow the same module to be specified for multiple IDL files that do not include each other within the same application 2) or extend the syntax to something that also allows a statement like module foo.bar.something; while keeping the existing syntax 3) or preferably do both. If this is again an issue with difficulty of mapping into some languages, a judgement call needs to be made between this constraint and the up to now best widely-used namespace management scheme from the Java world that uses reverse domain names. Best regards, Johannes Ernst Integrated Systems Inc. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 20 Mar 1998 10:19:26 +1000 (EST) From: Michi Henning To: Johannes Ernst cc: issues@omg.org Subject: Re: IDL "module" construct - IDL files On Thu, 19 Mar 1998, Johannes Ernst wrote: > It appears that the IDL concept of a module is tightly bound to > the storage of IDL statements in files. In other words, it does not > seem to be possible to distribute IDL statements in the same logical > module across multiple files. IDL allows you to re-open modules, which means that you can have different parts of the same module in different files. The only restriction with most (all?) current IDL compilers is that all of the IDL must be compiled at once. In practice, that's not hard to achieve. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: raz@goliath.apana.org.au Date: Fri, 20 Mar 1998 12:39:13 +1100 From: Roland Turner Organization: - To: Johannes Ernst CC: issues@omg.org Subject: Re: IDL "module" construct - IDL files References: Johannes Ernst wrote: > It appears that the IDL concept of a module is tightly bound to > the storage of IDL statements in files. IDL permits any given module to be reopened any number of times across any number of files. Any compiler failing to permit this is non-compliant. Perhaps you could explain what you mean by "it seems"? > In other words, it does not > seem to be possible to distribute IDL statements in the same logical > module across multiple files. What do you mean "seem"? Does your compiler generate an error message? > Consequently, few people use the > concept, and name collisions occur sooner or later when trying to > integrate systems that have not been developed by only one group. The Java language has had (and the Java standard library has used) packages (similar idea to IDL modules) since day one. Some developers still don't use them. Unsurprisingly such developers encounter conflicts. My point: there will always be developers who engineer poorly and they will encounter difficulties as a result. Those developers who make use of the facilities that their environments/languages offer to prevent problems, will have fewer problems! > Instead, I propose to > 1) either explicitely allow the same module to be specified for > multiple IDL files that do not include each other within the > same application Nothing prohibits this. > 2) or extend the syntax to something that also allows a statement like > module foo.bar.something; > while keeping the existing syntax What does this buy us? - Raz Return-Path: Date: Fri, 20 Mar 1998 09:52:13 -0800 X-Sender: ernst@postal.isi.com References: To: Roland Turner From: Johannes Ernst Subject: Re: IDL "module" construct - IDL files Cc: issues@omg.org >> It appears that the IDL concept of a module is tightly bound to >> the storage of IDL statements in files. > >IDL permits any given module to be reopened any number of times >> across >any number of files. Any compiler failing to permit this is >non-compliant. Can you point me to a particular place in the spec where it is stated that one can? I've not been able to find one. So I can do this? file1.idl: module MyTop { module MyBottom { interface Foo { .... }; }; }; file2.idl: module MyTop { module MyBottom { interface Bar { Foo someOperation(); ... }; }; }; Do I need an #include statement? If so, which file includes which? [which is the other "derived" issue of my point that I had not mentioned yet: reopening modules seems to collide with the #include idea, which, IMHO, hasn't be a particularly good one ever in any language] Also, last time I checked a forward-declaration along the lines of interface Something::SomethingElse::MyInterface; was not legal either. I suspect it still is. > Does your compiler generate an error message? The issue I'm raising is not a product implementation issue. It's simply a question of "what does the spec say", and "should it say what it says". Then I can go to my vendor and say "but you aren't doing this" (and I think issues@omg.org is not the place to discuss this ...) >The Java language has had (and the Java standard library has used) >packages (similar idea to IDL modules) since day one. Some developers >still don't use them. Unsurprisingly such developers encounter >conflicts. My basic proposal is indeed "make IDL modules to work like Java packages". And the goal is to make the IDL "module" concept actually usable. Thanks for everyone's time. Cheers, Johannes. Return-Path: Sender: jon@floorboard.com Date: Fri, 20 Mar 1998 11:45:27 -0800 From: Jonathan Biggar To: Johannes Ernst CC: Roland Turner , issues@omg.org Subject: Re: IDL "module" construct - IDL files References: Johannes Ernst wrote: > So I can do this? > file1.idl: > module MyTop { > module MyBottom { > interface Foo { > .... > }; > }; > }; > > file2.idl: > module MyTop { > module MyBottom { > interface Bar { > Foo someOperation(); > ... > }; > }; > }; > > Do I need an #include statement? If so, which file includes which? > [which is the other "derived" issue of my point that I had not > mentioned yet: reopening modules seems to collide with the #include > idea, which, IMHO, hasn't be a particularly good one ever in any > language] Yup, you can do that, and don't need an include. There are plenty of people who feel that include should be replaced with a safer mechanism. > Also, last time I checked a forward-declaration along the lines of > > interface Something::SomethingElse::MyInterface; > > was not legal either. I suspect it still is. Nope, but since you can reopen modules, you don't need it. > The issue I'm raising is not a product implementation issue. It's > simply a question of "what does the spec say", and "should it say > what it says". Then I can go to my vendor and say "but you aren't > doing this" (and I think issues@omg.org is not the place to discuss > this ...) This is standard behavior. > >The Java language has had (and the Java standard library has used) > >packages (similar idea to IDL modules) since day one. Some > developers > >still don't use them. Unsurprisingly such developers encounter > >conflicts. > > My basic proposal is indeed "make IDL modules to work like Java > packages". And the goal is to make the IDL "module" concept > actually usable. Just be careful to not propose stuff that is great for Java, but won't work for other languages. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sat, 21 Mar 1998 10:29:43 +1000 (EST) From: Michi Henning To: Johannes Ernst cc: Roland Turner , issues@omg.org Subject: Re: IDL "module" construct - IDL files On Fri, 20 Mar 1998, Johannes Ernst wrote: > >IDL permits any given module to be reopened any number of times across > >any number of files. Any compiler failing to permit this is > >non-compliant. > > Can you point me to a particular place in the spec where it is > stated that one can? I've not been able to find one. It's in section 3.13, page 3-35: Subsequence occurrences of a module declaration with the same scope reopen the module allowing additional information to be added to it. > > So I can do this? > file1.idl: > module MyTop { > module MyBottom { > interface Foo { > .... > }; > }; > }; > > file2.idl: > module MyTop { > module MyBottom { > interface Bar { > Foo someOperation(); > ... > }; > }; > }; I don't see why not. Any restrictions will be imposed by your compiler. For example, when you compile file2.idl, the compiler will need to have seen file1.idl, otherwise it won't know about the type of Foo. However, how to achieve this is an implementation issue. A compiler may force you to compile both modules at once, or it may offer some separate compilation mechanism. > Do I need an #include statement? If so, which file includes which? As I said, it depends on your compiler. > [which is the other "derived" issue of my point that I had not > mentioned yet: reopening modules seems to collide with the #include > idea, which, IMHO, hasn't be a particularly good one ever in any > language] Agreed. Several other people have stated here in the past that some form of import mechanism may be better. > Also, last time I checked a forward-declaration along the lines of > > interface Something::SomethingElse::MyInterface; > > was not legal either. I suspect it still is. That forward declaration isn't legal because the grammar requires a simple, unqualifed identifier for the forward declaration. You get around this by writing: module A { interface AI; // Forward declaration }; module B { interface BI { void op(in A::AI ai_ref); // OK, AI is known }; }; module A { interface AI { // Complete definition void op(in B::BI bi_ref); }; }; That way, you can have mutually dependent interfaces in two different modules. 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