The protected OCLHelperImpl::getEnvironment() method returns the "root"
environment of the OCL that created it only in the case that it doesn't,
yet, have its own environment. The OCLHelper cannot create an environment
until it knows what its context is (as Classifier, Operation, or Property).

You shouldn't need to create a new OCL instance on the same environment as
another. That just makes another object that you will have to dispose()
when you are finished with it (the OCL::dispose() method is new in 1.2 M4
to cover a requirement to "dispose" EMF objects by unloading them or
clearing their adapter-lists; this is particularly important to prevent
memory leaks in UML's CacheAdapter).

You can add variable definitions to the OCL's root environment; the helper
will see them when it parses expressions. You can then remove the
variables when you have finished, if you want to re-use the same OCL for
further parsing. This is particularly convenient because, every time that
the helper's context is changed to parse another expression, its
environment is destroyed and a new one is created. So, you'd have to be
recreating your variables every time you set the helper's context. by
creating the variables in the root environment, every new helper
environment will inherit them.

Thank you for your email. We've based our even-action processing code on top
of your OCL implementation.

Similar to OCL OperationCalls, we also contribute variables to the
environment, in potentially nested contexts. For clarity: that method I have
given below can be called more than once, each call introducing additional
variables.

Since we no longer can control the nesting of Environments that is held
privately by OCLHelper, we now need to create our own EvaluationEnvironment
type of object where we keep track of variables which we can only contribute
to the root OCL Environment. It is doable, but totally reduandant, given
that is what OCL EvaluationEnvironment is for.

Perhaps you can let us register our own subclass of OCL.Helper so that we
can get access to the environment so that we can control the nesting of the
environments?

Adding custom operations is necessarily more complex than adding variables,
because that requires a custom environment implementation. I agree that
the helper's environment should be more accessible.

If you would raise an enhancement request, I'll see what we can do to
address it.

Thanks,

Christian

Yucel Turkkan wrote:

> Christian,
>
> Thank you for your email. We've based our even-action processing code on
> top of your OCL implementation.
>
> Similar to OCL OperationCalls, we also contribute variables to the
> environment, in potentially nested contexts. For clarity: that method I
> have given below can be called more than once, each call introducing
> additional variables.
>
> Since we no longer can control the nesting of Environments that is held
> privately by OCLHelper, we now need to create our own
> EvaluationEnvironment type of object where we keep track of variables
> which we can only contribute
> to the root OCL Environment. It is doable, but totally reduandant, given
> that is what OCL EvaluationEnvironment is for.
>
> Perhaps you can let us register our own subclass of OCL.Helper so that we
> can get access to the environment so that we can control the nesting of
> the environments?
>
> Thanks for your consideration,
>
> Yucel