Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflexive reference cannot be operatored (#98) #109

Open
StephanErb opened this issue Aug 23, 2011 · 1 comment
Open

Reflexive reference cannot be operatored (#98) #109

StephanErb opened this issue Aug 23, 2011 · 1 comment

Comments

@StephanErb
Copy link
Member

Using the current implementation we cannot define a reflexive reference as being operatored at the same time. For example, as we would like to use for qualified name resolving for ECore elements:

-- A modelClassifier is either its ePackage followed by :: and a name, or just a name
template ecore::EClassifier referenceOnly --should never be created
: ( isDefined(ePackage) ? ePackage { mode = noop } "::" name : name)
;

 -- EPackage gets operatored using the :: operator to resolve left recursion
    template ecore::EPackage #noop abstract operatored(DBLCOLON);


    -- if parsed path has more than one element, 
    template ecore::EPackage referenceOnly -- should never be created
            : name
            ;

    -- any following elements in a package path will be resolved using this
    operatorTemplate ecore::EPackage(operators =
                    opDlColon, source = 'eSuperPackage') referenceOnly -- should never be created
            :       name
            ;

There are two problems with this:

  1. Operatored and OperatorTemplates currently do not support being moded.
  2. A primary template that would terminate the recursion is currently determined as concrete templates of the subtype of the operatored template. In the example above, however, it is the same class. Therefore, the grammar generation fails with "ERROR: No template for concrete subclass found to be able to terminate operator this template"
@StephanErb
Copy link
Member Author

Thomas Goldschmidt ([email protected]) wrote on 2011-02-22 12:21:59

I implemented a workaround allowing at least two packages as chained parents in the template definitions:
 
 -- if parsed path has more than one element, (workaround for bug #98)
        template ecore::EPackage referenceOnly -- should never be created
        :       
                [[
                        nsURI {as = uriSymbol} "#"
                      |
                        (isDefined(eSuperPackage) ? eSuperPackage { mode = superPackage}  ) name "::"
                ]]
        ;
        
        --workaround for bug #98
        template ecore::EPackage referenceOnly #superPackage -- should never be created
        :       
                [[
                        nsURI {as = uriSymbol} "#"
                      |
                        name "::"
                ]]
                
        ;
 
As you can see I also added the possibility to refer to packages via their nsURI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant