Issue 4579: CCM: Meaning of "exposed" scopes unclear. (components-ftf) Source: Humboldt-Universitaet (Mr. Martin von Loewis, loewis(at)informatik.hu-berlin.de) Nature: Uncategorized Issue Severity: Summary: ccm/01-08-04 says "When a name scope is imported, the names of the enclosing scopes in the fully-qualified pathname of the enclosing scope are exposed within the context of the importing specification, but their contents are not imported. An importing specification may not re-define or re-open a name scope which has been exposed (but not imported) by an import statement." Now consider the following "well-defined set of IDL specs": module X { module Y { module Z{}; }; }; and the following import statement import X::Y; Now, it appears that this declaration would make it ill-formed to specify module X{ interface another_interface{}; }; since "X" is an exposed scope. That appears to be inconsistent, since clearly, reopening "X" is allowed without the import statement. Resolution: see below Revised Text: In ccm/01-08-03 section 3.6 page 3-21 replace • When a name scope is imported, the names of the enclosing scopes in the fully-qualified pathname of the enclosing scope are exposed within the context of the importing specification, but their contents are not imported. An importing specification may not re-define or re-open a name scope which has been exposed (but not imported) by an import statement. with • An import statement makes the contents of the imported scope accessible without qualification, but has no effect on the contents of the enclosing scopes. Actions taken: September 17, 2001: received issue May 13, 2002: closed issue Discussion: As indicated by the author of the issue, denying the reopening of visible name scopes is inconsistent with the behavior of a similar non-importing specification. Conceptually, there is no issue in defining or opening name scopes that are identical to visible name scopes since only imported scopes can be directly referenced or reopened (in the case of modules). End of Annotations:===== Date: Mon, 17 Sep 2001 18:52:59 +0200 (MEST) Message-Id: <200109171652.SAA25506@pandora.informatik.hu-berlin.de> X-Authentication-Warning: pandora.informatik.hu-berlin.de: loewis set sender to loewis@informatik.hu-berlin.de using -f From: Martin von Loewis To: issues@omg.org, components-ftf@omg.org Subject: CCM: Meaning of "exposed" scopes unclear. User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-UIDL: Q!&!!%f`!!LR;e9%ZNe9 ccm/01-08-04 says "When a name scope is imported, the names of the enclosing scopes in the fully-qualified pathname of the enclosing scope are exposed within the context of the importing specification, but their contents are not imported. An importing specification may not re-define or re-open a name scope which has been exposed (but not imported) by an import statement." Now consider the following "well-defined set of IDL specs": module X { module Y { module Z{}; }; }; and the following import statement import X::Y; Now, it appears that this declaration would make it ill-formed to specify module X{ interface another_interface{}; }; since "X" is an exposed scope. That appears to be inconsistent, since clearly, reopening "X" is allowed without the import statement. Regards, Martin From: "Bernard Normier" To: Subject: Issue #4579 Date: Tue, 6 Nov 2001 15:59:01 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DB_01C166DB.F3BDAE90" X-UIDL: G^]!!mCMe9XZ]d9>f?!! Hi, I'm not too happy with the proposed resolution to issue #4579: "When a name scope is imported, the names of the enclosing scopes in the fully-qualified pathname of the enclosing scope are visible within the context of the importing specification, but their contents are not imported. An importing specification may redefine a name scope which is made visible (but not imported) by an import statement." An import statement has no effect on the enclosings scopes: it does not make them more or less visible. I'd prefer something like: "An import statement makes the contents of the imported scope accessible without qualification, but has no effect on the contents of the enclosing scopes". Thanks, Bernard X-Sender: evans@mail.cpi.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Nov 2001 16:50:43 -0500 To: "Bernard Normier" , From: "J. Scott Evans" Subject: Re: Issue #4579 In-Reply-To: <02e101c16705$e2505f20$4985413f@boston.amer.iona.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_685919406==_.ALT" X-UIDL: <"nd9g&4!!Toi!!bMAe9 Hi Bernard, At 03:59 PM 11/6/01 -0500, Bernard Normier wrote: Hi, I'm not too happy with the proposed resolution to issue #4579: "When a name scope is imported, the names of the enclosing scopes in the fully-qualified pathname of the enclosing scope are visible within the context of the importing specification, but their contents are not imported. An importing specification may redefine a name scope which is made visible (but not imported) by an import statement." An import statement has no effect on the enclosings scopes: it does not make them more or less visible. I choose these words based on some existing text that referenced the "visibility" of scopes. I must admit that I struggled to capture the notion that "visibility" in this context means that enclosing scopes "appeared in a qualified imported scope". I'd prefer something like: "An import statement makes the contents of the imported scope accessible without qualification, but has no effect on the contents of the enclosing scopes". I like it, concise and clear. Thanks for your input. Philippe, do you mind changing the text if no one disagrees? Scott Thanks, Bernard From: Philippe.Merle@lifl.fr Received: from (merle@localhost) by karjala.lifl.fr (8.9.1b+Sun/jtpda-5.3.3) id LAA21381 ; Wed, 7 Nov 2001 11:48:40 +0100 (MET) Date: Wed, 7 Nov 2001 11:48:40 +0100 (MET) Message-Id: <200111071048.LAA21381@karjala.lifl.fr> To: bnormier@iona.com, components-ftf@omg.org, evans@cpi.com Subject: Re: Issue #4579 X-Sun-Charset: US-ASCII Content-Type: text X-UIDL: e'$!! From: "J. Scott Evans" > Subject: Re: Issue #4579 > > Hi Bernard, > > At 03:59 PM 11/6/01 -0500, Bernard Normier wrote: > >Hi, > > > >I'm not too happy with the proposed resolution to issue #4579: > >"When a name scope is imported, the names of the enclosing scopes > in the > >fully-qualified pathname of the enclosing scope are visible within > the > >context of the importing specification, but their contents are not > >imported. An importing specification may redefine a name scope > which is > >made visible (but not imported) by an import statement." > > > >An import statement has no effect on the enclosings scopes: it does > not > >make them more or less visible. > > I choose these words based on some existing text that referenced the > "visibility" > of scopes. I must admit that I struggled to capture the notion that > "visibility" in > this context means that enclosing scopes "appeared in a qualified > imported > scope". > > >I'd prefer something like: > >"An import statement makes the contents of the imported scope > accessible > >without qualification, but has no effect on the contents of the > enclosing > >scopes". > > I like it, concise and clear. Thanks for your input. Philippe, do > you > mind changing > the text if no one disagrees? Thanks you Bernard for your input. I agree with it and integrate it into the Vote 8. A+ Philippe Merle -- ___________________________________________________________________________ Dr. Philippe Merle - Associate Researcher at INRIA Laboratoire d'Informatique Fondamentale de Lille UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3 Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq CEDEX France Tel: (33) (0)3 20 43 47 21 Fax: (33) (0)3 20 43 65 66 E-Mail: Philippe.Merle@lifl.fr Home Page: http://www.lifl.fr/~merle See also: http://corbaweb.lifl.fr/ ___________________________________________________________________________