Community
Participate
Working Groups
In my Reflections On OCL 2 paper, I identified CompleteClasses as one of the unsatisfactory aspects of the Pivot prototype. Code must remember to access the overlay. The original motivation for a deferred merge of overlays allows uncopied sharing, eases round-trip testing, has close UML alignment. But the whole goal is Open Classes and a normalized Pivot. If Pivot Classes are open CompleteClass is redundant, no longer an inconsistent need to access/find the overlay. The current esObject allows the original EObject to be found, but may require a search amongst alternatives and is troublesome when UML has a UML and Ecore origin. Re-instate round-tripping by replacing esObject by an esOrigin linked list of rich origin classes that describe what is/is not attributable to the merge. A shared Open Class will need to be 'contained' by multiple never-shared Open Packages. Ouch! How does a shared Class navigate to its not-shared subling? If we introduce a delegate we are back with the CompleteClass overlay problem. ? the 'CompleteModel' maintains a map from sharedElement to unsharedElement so that every access e.g. getType() must traversethe map to find the local variant. Or. A simple usage may be 100% shared using the built-in model. As soon as any custom Class/Feature is added to an existing Package/Class, a 100% copy of all metamodel elements is mandated. Only merges of the Package hiearrchy can have shared elements via Package.ownedPackages and Package.nestedPackages. TypeId etc are necessary to find the equivalent metamodel element in different complete metamodels or none.
(In reply to Ed Willink from comment #0) > If we introduce a delegate we are back with the CompleteClass > overlay problem. Using the CompleteModel involves two activities, loading open-classes and merging to closed clases. open and closed classes are distinct, and the merging involvestoo much clever addedXXX callbacks. THe merging is partially woven into the loaded so that each ES2AS or CS2AS has fragile refreshes. As soon as we support editing, we move to a need for reloading and remerging with the latter adding to the weaving difficulties. Debugging anOCLstdlib paste test revealed difficulties in ensuring that a merge correct prines stale content. This compoounds potential difficulties roundtrip testing merged model that lose their unmerged origins. Much better to have separate (re)losd and (re)merge with the remerge driven by a worklist of damaged elements. (Re)load is from ES/CS to PartialClass/Model/Package/... and (re)merging to CompleteClass/Model/Package/... Er, isn't this just what the current code does? Sort of but the loaded (Partial)Class is distinct from CompleteClass forcing non-loading code to be aware of the duality. If instead both PartialClass and CompleteClass extend the (Abstract)Class, non-loading code can use the neutral Class functionality without caring whether a lightweight single source PartialClass or complex multiple source CompleteClass is in use. So. 1. Import analyzer processes all imports transitively to determine which models are partial and which complete. Subsequently references terminate in the minimum complexity. 2. (Re)loader(s) refresh an isolated PartialModels and update damaged elements worklist. 3. (Re)merger processes the damed list and fleshes out the complete models. 4. Thereafter non-loading analysis code just uses the minimum complexity model. Bug 577825 considers how OCLSTdlib / OCLmetamodel adapt to this new perspective.
Bug 581543#1 outlines a compatible rationalization. FlatClass (formerly AbstractInheritance) comprises the efficient flat representation dynamically created when necessary or statically constructed by XXXTables when unmodified. PartialClass / CompleteClass are thin Ecore-based model structure classes delegating to the rich FlatClass. PartialClass / CompleteClass are used polymorphically as just Class.
