search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[environment] Clarify status of the global environment #648

Open eclipse-ocl-bot opened 4 weeks ago

eclipse-ocl-bot commented 4 weeks ago

| --- | --- | | Bugzilla Link | 338501 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 01, 2011 01:04 EDT | | Modified | Feb 22, 2021 13:23 EDT | | Version | 3.1.0 | | See also | 543221, 570995 | | Reporter | Ed Willink |

Description

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.

eclipse-ocl-bot commented 4 weeks ago

By Axel Uhl on Mar 02, 2011 06:53

(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

eclipse-ocl-bot commented 4 weeks ago

By Ed Willink on Mar 02, 2011 12:41

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.

eclipse-ocl-bot commented 4 weeks ago

By Ed Willink on Mar 08, 2011 08:40

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.

eclipse-ocl-bot commented 4 weeks ago

By Ed Willink on May 05, 2011 14:54

Deprecation of the global environment can exploit the introduction of an EnvironmentFactory EPackage EAnnotation.

eclipse-ocl-bot commented 4 weeks ago

By Ed Willink on Feb 14, 2021 07:03

(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'.

eclipse-ocl-bot commented 4 weeks ago

By Ed Willink on Feb 22, 2021 13:23

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 ...