eclipse-ocl-bot
commented
2 days ago By Ed Willink on Aug 14, 2017 07:47
(In reply to Ed Willink from comment #0)
Currently CollectionCompleteClassImpl / MapCompleteClassImpl use Type as
Except that we also have OrphanCompletePackageImpl.CompletePackageImpl inconsistently created for
MapType from CompleteClass.doRefreshPartialClass
CollectionType from CompleteEnvironmentImpl.getCompleteClass
It is CollectionTypes created by two different mechanisms that is actually causing the xmi:id ambiguity.
| --- | --- | | Bugzilla Link | 520938 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 14, 2017 07:13 EDT | | Modified | Aug 14, 2017 07:47 EDT | | Reporter | Ed Willink |
Description
The Bug 520529 problems are related to vague modeling of complete specializations.
CollectionCompleteClassImpl/MapCompleteClassImpl are currently nested in CompleteClasses pending better code. CollectionCompleteClassImpl was an experiment, MapCompleteClassImpl duplicated, but really the philosophy has been to treat CollectionType and MapType the same as specialized Classes and so the experimental code should be generalized to provide the missing support for specialized CompleteClasses?
What is a specialized CompleteClass? just the same as an ordinary CompleteClass; a logical merge of all the incomplete types that provide the complete functionality. In the case of specializations, incomplete types may be incomplete wrt one or more of the unspecialized type and the template bindings.
Currently CollectionCompleteClassImpl / MapCompleteClassImpl use Type as part of their lookup. This is surely wrong? it must be TypeId (or CompleteClass). TypeId is probably better allowing more uniformity for a globally shared facility.