Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMT (Generative Modeling Technologies) » [UMLX] Problem lookingup ambiguous classifiers qualified with its EPackage name
[UMLX] Problem lookingup ambiguous classifiers qualified with its EPackage name [message #379906] Mon, 08 October 2007 14:02 Go to next message
Eclipse User
Originally posted by: alu2526.etsii.ull.es

Hi Ed,



Taking a look to your implementation of classifier 's lookup, i have
detected some problems.



QVTEnvironment has a method which detects the ambiguity in the classifier
lookup, is tryLookupMetaModelClassifier, which delegates the search to the
method lookupMetaModelClassifiers. The problem is that this method only find
unqualified classifiers, or classifiers qualified by a metaModel ID, but It
does not take into account that a classifier could be qualified by package
name.



The problem is partly solved because try lookupMetaModelClassifier would
fail, and a classifier would be found in a normal
EcoreEnvironment.lookupClassifier. But ambiguous classifiers qualified by
its package name would not be detected. For example:



PackageNameA

+CommonPackageName

+AClassifier

PackageNameB

+CommonPackageName

+AClassifier



If we lookup comonPackageName::AClassifier we have an undetected ambiguity
of classifier's names.



Besides, when qualifying with a metaModel ID which represents a set of
packages, you could not find a nested package name, since the
QVTEnvironment.getPackagedClassifier implementation is not as complete as
EcoreEnvironment.lookupClassifier implementation is. Instead of having a map
<metaModelID, EPackages> (in QVTrTopLevelEnvironment or
QVTrTransformationEnvironment) and functions (lookupMetamodelClassifier,
getMetaModelContents, etc) to manage them, I encourage you to use
environments (QVTrTransformationEnvironments nest QVTrMetaModelEnvironments
which nest a set of QVTEnvironment which have a package context associated)
and exploit the use of EcoreEnvironment.lookupClassifier.



I have implemented a hierarchical set of environments for my QVTo
implementation, that perhaps it could be applied at a QVTEnvironment and
QVTrEnvironment abstraction level and shared for all QVTo, QVTr, QVTc
implementation to have a better classifier's lookup.



Regards,

Adolfo.
Re: [UMLX] Problem lookingup ambiguous classifiers qualified with its EPackage name [message #379921 is a reply to message #379906] Wed, 10 October 2007 06:42 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4088
Registered: July 2009
Senior Member
[The OCL background to this thread is https://bugs.eclipse.org/bugs/show_bug.cgi?id=176110]

Hi Adolfo

Now that MDT OCL lookup is evolving to accommodate lookup ambiguity in more
than just UML States, it is well worth revisiting all derived Environment
classes to provide consistent overrides of tryLookupXXXX that support the
Environment contract and 'return' an ambiguous result via a LookupException.

I'll do this once Christian has decided how to spell 'tryLookup' and whether
to support it by an adapter or a mix-in.

Failure to accommodate implicit wildcard meta-model, explicit package qualified
lookup is an oversight. At the time the QVT spec was very unclear about details
such as names, and so it was necessary to be intuitive as to what it meant for
standard OCL lookups to work in the presence of meta-model names.

Contrasting the various QVTrXxxEnvironment classes that I originally developed
with the QVTcXxxEnvironment classes that followed reveals a major refactoring
opportunity that could be very helpful for QVToXxxEnvironment. I'll look into this.

Regards

Ed Willink


Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Ed,
>
>
>
> Taking a look to your implementation of classifier 's lookup, i have
> detected some problems.
>
>
>
> QVTEnvironment has a method which detects the ambiguity in the classifier
> lookup, is tryLookupMetaModelClassifier, which delegates the search to the
> method lookupMetaModelClassifiers. The problem is that this method only find
> unqualified classifiers, or classifiers qualified by a metaModel ID, but It
> does not take into account that a classifier could be qualified by package
> name.
>
>
>
> The problem is partly solved because try lookupMetaModelClassifier would
> fail, and a classifier would be found in a normal
> EcoreEnvironment.lookupClassifier. But ambiguous classifiers qualified by
> its package name would not be detected. For example:
>
>
>
> PackageNameA
>
> +CommonPackageName
>
> +AClassifier
>
> PackageNameB
>
> +CommonPackageName
>
> +AClassifier
>
>
>
> If we lookup comonPackageName::AClassifier we have an undetected ambiguity
> of classifier's names.
>
>
>
> Besides, when qualifying with a metaModel ID which represents a set of
> packages, you could not find a nested package name, since the
> QVTEnvironment.getPackagedClassifier implementation is not as complete as
> EcoreEnvironment.lookupClassifier implementation is. Instead of having a map
> <metaModelID, EPackages> (in QVTrTopLevelEnvironment or
> QVTrTransformationEnvironment) and functions (lookupMetamodelClassifier,
> getMetaModelContents, etc) to manage them, I encourage you to use
> environments (QVTrTransformationEnvironments nest QVTrMetaModelEnvironments
> which nest a set of QVTEnvironment which have a package context associated)
> and exploit the use of EcoreEnvironment.lookupClassifier.
>
>
>
> I have implemented a hierarchical set of environments for my QVTo
> implementation, that perhaps it could be applied at a QVTEnvironment and
> QVTrEnvironment abstraction level and shared for all QVTo, QVTr, QVTc
> implementation to have a better classifier's lookup.
>
>
>
> Regards,
>
> Adolfo.
>
>
>
>
Re: [UMLX] Problem lookingup ambiguous classifiers qualified with its EPackage name [message #608136 is a reply to message #379906] Wed, 10 October 2007 06:42 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4088
Registered: July 2009
Senior Member
[The OCL background to this thread is https://bugs.eclipse.org/bugs/show_bug.cgi?id=176110]

Hi Adolfo

Now that MDT OCL lookup is evolving to accommodate lookup ambiguity in more
than just UML States, it is well worth revisiting all derived Environment
classes to provide consistent overrides of tryLookupXXXX that support the
Environment contract and 'return' an ambiguous result via a LookupException.

I'll do this once Christian has decided how to spell 'tryLookup' and whether
to support it by an adapter or a mix-in.

Failure to accommodate implicit wildcard meta-model, explicit package qualified
lookup is an oversight. At the time the QVT spec was very unclear about details
such as names, and so it was necessary to be intuitive as to what it meant for
standard OCL lookups to work in the presence of meta-model names.

Contrasting the various QVTrXxxEnvironment classes that I originally developed
with the QVTcXxxEnvironment classes that followed reveals a major refactoring
opportunity that could be very helpful for QVToXxxEnvironment. I'll look into this.

Regards

Ed Willink


Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Ed,
>
>
>
> Taking a look to your implementation of classifier 's lookup, i have
> detected some problems.
>
>
>
> QVTEnvironment has a method which detects the ambiguity in the classifier
> lookup, is tryLookupMetaModelClassifier, which delegates the search to the
> method lookupMetaModelClassifiers. The problem is that this method only find
> unqualified classifiers, or classifiers qualified by a metaModel ID, but It
> does not take into account that a classifier could be qualified by package
> name.
>
>
>
> The problem is partly solved because try lookupMetaModelClassifier would
> fail, and a classifier would be found in a normal
> EcoreEnvironment.lookupClassifier. But ambiguous classifiers qualified by
> its package name would not be detected. For example:
>
>
>
> PackageNameA
>
> +CommonPackageName
>
> +AClassifier
>
> PackageNameB
>
> +CommonPackageName
>
> +AClassifier
>
>
>
> If we lookup comonPackageName::AClassifier we have an undetected ambiguity
> of classifier's names.
>
>
>
> Besides, when qualifying with a metaModel ID which represents a set of
> packages, you could not find a nested package name, since the
> QVTEnvironment.getPackagedClassifier implementation is not as complete as
> EcoreEnvironment.lookupClassifier implementation is. Instead of having a map
> <metaModelID, EPackages> (in QVTrTopLevelEnvironment or
> QVTrTransformationEnvironment) and functions (lookupMetamodelClassifier,
> getMetaModelContents, etc) to manage them, I encourage you to use
> environments (QVTrTransformationEnvironments nest QVTrMetaModelEnvironments
> which nest a set of QVTEnvironment which have a package context associated)
> and exploit the use of EcoreEnvironment.lookupClassifier.
>
>
>
> I have implemented a hierarchical set of environments for my QVTo
> implementation, that perhaps it could be applied at a QVTEnvironment and
> QVTrEnvironment abstraction level and shared for all QVTo, QVTr, QVTc
> implementation to have a better classifier's lookup.
>
>
>
> Regards,
>
> Adolfo.
>
>
>
>
Previous Topic:[TCD]:BUILD FAILED.
Next Topic:[TCS] Problem building TCS Language project
Goto Forum:
  


Current Time: Tue Oct 21 20:08:55 GMT 2014

Powered by FUDForum. Page generated in 0.07107 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software