Community
Participate
Working Groups
Usage of the default and consequently global environment has recently been discouraged, if not formally deprecated, since in the context of evaluation the global environment implies a model extent of all registered packages which is expensive for allInstances() and model analysis. A different usage of the global environment occurs for OCLDelegateDomain where a shared EMF extending service is provided for all applications. This should not use an environment that favours the first application to activate the delegate domain, so should use the default global environment. Perhaps there should be a different default environment that is almost/totally empty for use by OCLDelegateDomain. Perhaps the sole default environment should be almost empty.
(In reply to comment #0) Ed, > Usage of the default and consequently global environment has recently been > discouraged, if not formally deprecated, since in the context of evaluation the > global environment implies a model extent of all registered packages which is > expensive for allInstances() and model analysis. can you be a bit more specific as to which "environment" you mean? The EcoreEnvironment instances? Or the EcoreEvaluationEnvironment instances? Or the OCL object(s)? Which part of allInstances() evaluation are you referring to? The LazyExtentMap implementation scans the entire resource/resource set, regardless of the packages in the EPackage registry. So I'm not sure I understand what you mean. > Perhaps there should be a different default environment that is almost/totally > empty for use by OCLDelegateDomain. Perhaps the sole default environment should > be almost empty. Probably, after you detailed the above it also becomes clearer what you mean by "almost/totally empty." Best, -- Axel
This is a somewhat philosphical memo to do some analysis and then design something sensible for all global objects that may be shared by multiple applications. A related problem that made me appreciate this inadequacy arises with DelegateDomains targeting a pivot. The delegate domain provides an extended EMF, but the application using the delegated OCL may use one of a variety of different OCL standard libraries. If one application has an overloaded OclAny::= and another doesn't, which OCL is used? Not actually a pivot problem, just that the pivot is cached for the selected semantics, so it highlights the inflexibility. Since the delegate domain cannot know which application's OCL semantics to use, it must use none of them and instead always use the neutral semantics that the releng feels is appropriate for all users.
Note that in https://bugs.eclipse.org/bugs/show_bug.cgi?id=339052 we discovered that: A: a delegating registry doesn't delegate the values() call to enumerate candidate packages. B: the package lookup of values() ignores packages whose package delegate has not already been resolved. Conclusions: B: the use of the 'global package registry' may give interminttent results. A: delegation to 'the global package registry' is almost useless. Users must therefore create and populate a custom package registry. Deprecation of the global registry can therefore be quite aggressive.
Deprecation of the global environment can exploit the introduction of an EnvironmentFactory EPackage EAnnotation.
(ntroduction of a LocalThreadExecutor for Bug 570995 suffers fromthe concurrent Global/non-GloablEnvironmentFactory and highlights a solution. Using the LocalThread the 'global' shared context can be 'local'.
The Pivot GlobalEnvironmentFactory is obsolete as of 6.14.0M3. The Pivot OCLDelegateDomain.ocl is probably obsolete - needs review THe Pivot QveryImpl has been abstracted as BasicQueryImpl without an OCL - needs review --- The Classic OCL could also move to a ThreadLocal ...
