Issue 14224: Inconsistent lookup for underscored symbols (ocl2-rtf) Source: (, ) Nature: Enhancement Severity: Significant Summary: Description: 9.3 Concrete Syntax As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_›, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried. Should be As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_», the symbol with the «_» skipped is looked up in the metamodel. Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here. Resolution: Discussion: Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward spellings. This solves the problem of accessing either _'self' or _'_self'. Revised Text: Actions taken: August 27, 2009: received issue April 25, 2011: closed issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Aug 2009 11:01:28 -0400 To: issues@omg.org, ocl2-rtf@omg.org From: Juergen Boldt Subject: issue 14224 -- OCL 2 RTF issue From: webmaster@omg.org Date: 27 Aug 2009 05:13:29 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Alexander Igdalov Company: Individual mailFrom: Alexander.Igdalov@gmail.com Notification: Yes Specification: Object Constraint Language Section: 9.3 Concrete Syntax FormalNumber: ptc/09-05-02 Version: 2.1 RevisionDate: 09-05-02 Page: 64 Title: Inconsistent lookup for underscored symbols Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: 9.3 Concrete Syntax As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_., firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried. Should be As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_», the symbol with the «_» skipped is looked up in the metamodel. Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD6J/kpUXebi/2dsb2JhbADTEoQ8BA Date: Sat, 14 Nov 2009 18:45:36 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "'ocl2-rtf@omg.org'" Subject: Re: Issue 14224 Inconsistent lookup for underscored symbols X-Plusnet-Relay: cf16f59f8a23b2b2cb441ae7cee29fbc Hi Attached adopts Alex's suggestion that _xxx always means xxx, and realises it as just another simpleNameCS mapping. Since Issue 14357 already rewrites the relevant simpleNameCS, the resolution is merged. Regards Ed Willink 14224-UnderscoreSymbols.odt Disposition: Merged OMG Issue No: 14224 Title: Inconsistent lookup for underscored symbols Source: Alexander Igdalov, Alexander.Igdalov@gmail.com Summary: 9.3 Concrete Syntax As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_., firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried. Should be As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_», the symbol with the «_» skipped is looked up in the metamodel. Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here. Discussion: The proposal provides for a simpler unambiguous implementation that works for all names and which does not require any semantic knowledge. Since the proposed implementation defines a mapping independent of the meta-model, the «_» is clearly just a syntactic key that selects an alternative CST to AST mapping. This can be accommodated in the simpleNameCS mapping eliminating any need for alternative lookup rules. The problem with reserved words potentially occurs in any context where a simpleNameCS occurs, so the references to property name and class name are unhelpful. Treating «_» as a prefix for the subsequent name, changes the default interpretation of the special QVTr identifier «_». Under OCL 2.1 parsing this was syntactically the identifier comprising a single «_» character. This resolution changes it to a prefixed usage of the empty name «». QVTr 1.0 tools that use OCL 2.3 parsing should therefore recognise «» rather than «_» as special. QVTr could define «_» as a reserved word to clarify the special status of «_» as an identifier and allow access to a conflicting «_» property in the metamodel as «__». Revised Text: See Issue 14357