Home » Modeling » OCL » Resolving Collection Types....
| Resolving Collection Types.... [message #54583] |
Wed, 30 April 2008 10:01  |
Eclipse User |
|
|
|
Hi Cristian...
I have some comments, ready for you when you come back :)
Take a look to the following error:
Validator-ERROR in org.eclipse.emf.ecore.model; Encapsulation.qvto:3 :
There may not be two classifiers named 'Set(Element)'
Comment 1:
This error appears, because several Set(Element) have been resolved and
created by the type resolver. This multiple creation seems to be valid,
since Element is not the same element type of the sets. I mean, both
Element(s) are different types (with the same name), so they are
different Set(Elements).
One solution which could solve this error reporting, is adding a new
constraint to change the EcoreValidator behaviour. I have not looked
into that, but it seems to be an EPakage constraint, so I would need to
add overwrite the EcoreValidator constraint in my QVTo::Module (which
extends EPackage and encloses the generated types) to avoid the error
reporting. However, I'm not very confidence of taking this kind of
decisions, every time I have a conflict with the EcoreValidator
constraints. It's supposed that QVTo/EQVTo extends Emof/Ecore, so this
metamodel constraints shouldn't be freely skipped by QVTo/EQVTo models.
More nasty thoughts work around:
1. Organizing the packages managed by the type resolver
2. Collection's names
....
Nothing convinces me...If you want to include any kind of thoughts,
suggestions, etc.
Comment 2:
One of the Set(Element), is a collection which should belong to the
QVToStandardLibrary, since it's a type of a returned value and/or needed
parameter by several standard library operations.
Due to, the type resolver used during the parsing process is not the
same type resolver used when constructing the StandardLibrary (Different
type resolvers which resolve, generate, and persist types in different
resources), the former will create types even the latter have created
them previously.
Therefore, I have the same type generated twice, one in the
StandardLibrary ( qvtotdlib::collections::Set(Element) ) and the other
in the output model (encapsulation::Set(Element)), when it seems that
the second type should not be generated any more, and the type resolver
should return the stdblid one.
Maybe, it could be reasonable "connecting", in some way, the
typeresolver with the stdlib package..., What do you think ?
This seems to be a similar problem reported some weeks (months?) ago. In
that case the type resolver created the generic instances of the
oclstdlib. This issue seems to be the same, but in this case related to
types generated (in collection/tuple/... packages) during stdblib
construction (which belong to the stdlib).
Cheers,
Adolfo.
|
|
|
| Re: Resolving Collection Types.... [message #54831 is a reply to message #54583] |
Sun, 04 May 2008 10:14  |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
Hi, Adolfo,
See some replies in-line, below.
HTH,
Christian
On Wednesday 04-30-2008 (10:01), Adolfo Sánchez-Barbudo Herrera
wrote:
> Hi Cristian...
> I have some comments, ready for you when you come back :)
Heh heh .. piling up the work for me, eh?
> Take a look to the following error:
> Validator-ERROR in org.eclipse.emf.ecore.model; Encapsulation.qvto:3
> : There may not be two classifiers named 'Set(Element)'
> Comment 1:
> This error appears, because several Set(Element) have been resolved
> and created by the type resolver. This multiple creation seems to be
> valid, since Element is not the same element type of the sets. I
> mean, both Element(s) are different types (with the same name), so
> they are different Set(Elements).
Yes, this looks like the EPackage constraint that requires unique
EClassifier names. The reason is that generating code from an
EPackage that has replicated EClassifier names results in ill-formed
Java (repeated identifiers). One could argue that this constraint
should be implemented in the genmodel only, but UML does have a
distinguishable-names constraint for Namespaces and probably EMOF has
the same for Packages.
The problem with OCL is that it specifies what the name of a
collection type should look like (check out the constraints in the
Types package, Chapter 8) but these name constraints are entirely
superfluous: the collection-type name is never used in parsing to
resolve the type! The collectionTypeCS production parses the element
type separately from the collection kind, so qualified names may be
required to resolve ambiguous references.
In all likelihood, this unique-names constraint should not be checked
on packages managed by a type-resolver.
> One solution which could solve this error reporting, is adding a new
> constraint to change the EcoreValidator behaviour. I have not looked
> into that, but it seems to be an EPakage constraint, so I would need
> to add overwrite the EcoreValidator constraint in my QVTo::Module
> (which extends EPackage and encloses the generated types) to avoid
> the error reporting. However, I'm not very confidence of taking this
> kind of decisions, every time I have a conflict with the
> EcoreValidator constraints. It's supposed that QVTo/EQVTo extends
> Emof/Ecore, so this metamodel constraints shouldn't be freely skipped
> by QVTo/EQVTo models.
Yes, but this is just another case where OCL is inconsistent with
EMOF/UML. It's probably best to be pragmatic and bend the OCL rules.
> More nasty thoughts work around:
> 1. Organizing the packages managed by the type resolver
> 2. Collection's names
> ....
The default implementation of the type resolver's package management
is quite simplistic. Probably you will need something more robust in
your QVT environment, as the QVT spec is generally much more explicit
in the definitions of packages than is OCL. For example, I could see
a QVT type resolver creating separate collection packages for each
model package in which element-types are referenced.
As I mentioned already, the collection names are quite unimportant to
OCL, so changing the way they are produced is probably not worthwhile.
Or, by the same token, it may be quite harmless :-)
> Nothing convinces me...If you want to include any kind of thoughts,
> suggestions, etc.
> Comment 2:
> One of the Set(Element), is a collection which should belong to the
> QVToStandardLibrary, since it's a type of a returned value and/or
> needed parameter by several standard library operations.
> Due to, the type resolver used during the parsing process is not the
> same type resolver used when constructing the StandardLibrary
> (Different type resolvers which resolve, generate, and persist types
> in different resources), the former will create types even the latter
> have created them previously.
I recently resolved a bug in which certain collection types already
defined in the OCL stdlib were being re-created in the type resolver.
I resolved this by enhancing the resolver to recognize those types
that are already defined by the stdlib and replying with those types
instead of creating new ones. I imagine it would be straight-forward
to do the same in the QVT environment.
> Therefore, I have the same type generated twice, one in the
> StandardLibrary ( qvtotdlib::collections::Set(Element) ) and the
> other in the output model (encapsulation::Set(Element)), when it
> seems that the second type should not be generated any more, and the
> type resolver should return the stdblid one.
> Maybe, it could be reasonable "connecting", in some way, the
> typeresolver with the stdlib package..., What do you think ?
I think so ... I already did this in OCL :-)
> This seems to be a similar problem reported some weeks (months?)
> ago. In that case the type resolver created the generic instances of
> the oclstdlib. This issue seems to be the same, but in this case
> related to types generated (in collection/tuple/... packages) during
> stdblib construction (which belong to the stdlib).
> Cheers,
> Adolfo.
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
Goto Forum:
Current Time: Mon Nov 03 20:45:45 EST 2025
Powered by FUDForum. Page generated in 0.03649 seconds |
Home