[Feature] read Ecore generics (EGenericType/ETypeParameter) and operation exceptions; fixes #97#102
Merged
Merged
Conversation
EcoreNetto silently dropped the Ecore generics facility (EGenericType/ETypeParameter and the eGenericType/eGenericSuperTypes/eTypeParameters/eGenericExceptions/eBounds containments), and EOperation.EExceptions was declared but never populated. Models using bounded or parameterized types lost that information without any diagnostic. Adds the EGenericType and ETypeParameter model classes and deserializes all generic containments: - ETypedElement.eGenericType (features, operations, parameters) - EClass.eGenericSuperTypes - EClassifier.eTypeParameters and EOperation.eTypeParameters - EOperation.eGenericExceptions and the eExceptions attribute - ETypeParameter.eBounds and nested EGenericType eTypeArguments/eUpperBound/eLowerBound EGenericType is not an ENamedElement (not cached), so its cross-references (eClassifier, eTypeParameter) are resolved in the second pass by the containing element propagating SetProperties into it. eClassifier/eTypeParameter/eExceptions are added to the reference-attribute rewrite so implicit '#//' references resolve. The erased views are kept complete: EType is derived from a generic type's raw classifier, generic super types feed ESuperTypes, and generic exceptions feed EExceptions. Adds GenericTypeTestFixture (type parameters + bounds, generic feature type + type-parameter argument, wildcard upper/lower bounds, generic super types + erased ESuperTypes, exceptions from both the attribute and generic forms, operation type parameters). Verified end-to-end: EcoreNetto now reads EMF's canonical Ecore.ecore (which uses eTypeParameters/eGenericType/eTypeArguments) without error.
Contributor
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #97. EcoreNetto silently dropped the Ecore generics facility, and
EOperation.EExceptionswas declared but never populated — a model using bounded/parameterized types or operation exceptions
lost that information with no diagnostic. EMF's own
Ecore.ecoreuses generics, so EcoreNetto couldread it (post #96) but discarded the generic type information.
What's added
Two new model classes and deserialization of every generic containment:
EGenericType—eClassifier,eTypeParameter,eTypeArguments,eUpperBound,eLowerBound.ETypeParameter—eBounds.ETypedElement.eGenericType(features/operations/parameters),EClass.eGenericSuperTypes,EClassifier.eTypeParameters,EOperation.eTypeParameters,EOperation.eGenericExceptions, and theeExceptionsattribute.Design notes
EGenericTypeis not anENamedElement, so it is not registered in the resource cache and thesecond-pass loop never visits it directly. Its cross-references (
eClassifier,eTypeParameter) areresolved by the containing element propagating
SetPropertiesinto it (the same patternEModelElementuses forEAnnotations);EGenericTyperecurses into its own nested generic types.eClassifier,eTypeParameterandeExceptionsare added to the reference-attribute rewrite soimplicit
#//references get the resource segment prepended and resolve likeeType/eSuperTypes.ETypeParameteris name-based (<container>#//Class/E), so type-variable references resolve bydirect cache hit.
ETypeis derived from a generic type's raw classifier when the typeis expressed only generically; generic super types also feed
ESuperTypes; generic exceptions alsofeed
EExceptions. So existing consumers ofEType/ESuperTypes/EExceptionskeep working.Changes
ECoreNetto/ModelElement/EGenericType.cs,ECoreNetto/ModelElement/NamedElement/ETypeParameter.cs.EObject.cs(reference-attribute list),ETypedElement.cs(eGenericType+ETypederivation),
EClassifier.cs(eTypeParameters),EClass.cs(eGenericSuperTypes+ESuperTypesderivation),
EOperation.cs(EExceptions,eTypeParameters,eGenericExceptions).ECoreNetto.Tests/Resource/GenericTypeTestFixture.cs(6 tests).Verification
Full solution test suite is green:
End-to-end:
ecoretools inspect -i <EMF>/model/Ecore.ecorecompletes (exit 0) — EcoreNetto reads thecanonical Ecore metamodel, now including its
eTypeParameters/eGenericType/eTypeArguments.Closes #97