[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.modeling.mdt.ocl] Re: def expression?

Hi Joel

Nested environments are appropriate for nested parsing and possibly evaluation of a complex expression. My recommendations were for parsing.

It seems that you have some bigger application that provides context across OCL evaluations.

You have described a push-model whereby the application continually
pushes its context to OCL.

You might find it worthwhile to create a derived EcoreEnvironment
that reimplements at least lookupLocal so that you can reuse the environment and just pull your application resolutions when you want them.


	Regards

		Ed Willink

Joel Greenyer wrote:
Hi Ed,
I'm afraid that that doesn't help me yet...

Again: I want to be able to evaluate constraints in an environment/evaluationEnvironment where I can specifically define the available variables and their bindings.


What I extract from the code snippets is that you create a nested environment by using the appropriate constructor of the ECoreEnvironment that takes the parent environment as parameter--okay.


My question is, however:
1. How do I make sure that this nested environment is used when I call
ocl.evaluate(context, expression)
the next time.

2. And, how can I control to again evaluate an expression with an outer environment?

3. And, probably I have to create nested evaluationEnvironments also. How do I deal with those?


Is it maybe easier to just dispose the old OCL and create new one and initialize it with the variables+bindings every time I evaluate a constraint?--That doesn't seem to be the way to use OCL though...



Thanks for helping

Joel



Ed Willink wrote:
Hi Joel

The following snippets all come from org.eclipse.qvt.declarative.parser or org.eclipse.qvt.declarative.parser.qvtrelation with added C++-style class names for clarity.

/**
 * Overridden to provided a nested scope for nested variables.
 */
@Override
protected OCLExpression<EClassifier> AbstractQVTAnalyzer::letExp(
    LetExpCS letExpCS,
    Environment<EPackage, EClassifier, EOperation,
    EStructuralFeature, EEnumLiteral, EParameter, EObject,
    CallOperationAction, SendSignalAction, Constraint, EClass,
    EObject> env) {
    return super.letExp(letExpCS,
        createdNestedEnvironment(letExpCS, env));
    }

@Override
protected IQVTrNodeEnvironment AbstractQVTrAnalyzer::createdNestedEnvironment(CSTNode cstNode,
Environment<EPackage, EClassifier, EOperation,
EStructuralFeature, EEnumLiteral, EParameter, EObject,
CallOperationAction, SendSignalAction, Constraint, EClass,
EObject> env) {
return new
QVTrNestedEnvironment((IQVTrNodeEnvironment)env,
cstNode);
}



public class QVTrNestedEnvironment extends QVTrEnvironment<IQVTrNodeEnvironment, EModelElement, CSTNode>
{
public QVTrNestedEnvironment(IQVTrNodeEnvironment env, CSTNode cstNode) {
super(env, null, cstNode);
} }


the construction just propagates down through 7 level of inheritance to an EcoreEnvironment.

The initial letExp override for AbstractOCLAnalyzer::letExp just ensures that the let body has a nested environment, which is instantly forgotten about when proceeding past the let.

    Regards

        Ed Willink


Joel Greenyer wrote:
Ed,
I've been trying to get familiar with nested environments, You promised that they were easy to use ;), but unfortunately I can't find code examples--at least not any that point in the direction that I need to go.


In short, my problem is that I match a graph pattern to a model and, during the matching process, I need a scope that constantly reflects the bound nodes by bound variables, i.e. the scope must contain a bound variable per named node that is currently bound.

While I backtrack, I need to remove variables from my environment/scope that will possibly be added again. So, you suggest to do this with nested environments--How do I create a nested environment (I think I understood that...) and how to I go back to an outer environment when I backtrack?

Thanks for helping!

Joel


Ed Willink wrote:
Hi Joel
I'm not sure about your whole problem but when you mention removing variables from environments I get very uncomfortable.

Why is that?

It means that the Environment has a very clear locality. Nested environments are always valid for the context that initialised them.


Note that OCL 2.0 does not support remove of elements from an Environment.

It is much easier
to created a nested environment for the nested scope and revert to the
outer ebvironment when you want to recover context.

You'll find nested environments are easy too, and you cannot forget to match your adds with removes.

I haven't worked with these nested environments yet, but I'll keep it in mind. However, I'd have to create a nested environment for each variable that I add. Adding and removing variables is easy and works well for me so far.

If it works for you fine. Just beware that if you start to do more interesting things, it might bite later.


    Regards

Ed Willink