Home » Modeling » OCL » OCL Validator error.
|
| Re: OCL Validator error. [message #53993 is a reply to message #53939] |
Wed, 16 April 2008 18:18   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
Find some replies in-line, below.
Cheers,
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> The following Error obtained from my test cases:
>
> Validator-ERROR in org.eclipse.emf.ecore.model; IfExp.qvto:1 : The
> instance type name 'null' is not well formed
>
> After debugging it (the info is not clear enough), the error is arisen
> due to CollectionTypeImpl doesn't have an instance class established in
> the same way as the remaining collections have.
>
> Suggestions
>
> 1. In CollectionTypleImpl add the missing
> setInstanceClass(java.util.Collection.class) to each constructor ->
> bugzilla
The subclasses of CollectionTypeImpl set "concrete" instance classes. OCL
should never create instances of collection types, but only its concrete
subtypes. So, I don't expect that this would ever cause problems, but I
guess there's no harm in setting the instance class. Please, do raise an
enhancement request.
> 2. What about suggesting EMF to include more information reported by the
> EClassifier::WellFormedInstanceTypeName constraint, such us including
> the name of classifier ?
Well, I suppose, technically, the name would be redundant, as
double-clicking the problem marker will select the problem element in the
editor. However, it would be nice to see this information at a glance in
the Problems view. Sounds like a good enhancement request for EMF.
> Regards,
> Adolfo.
|
|
|
| Re: OCL Validator error. [message #53998 is a reply to message #53993] |
Thu, 17 April 2008 10:00 |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Some in-lined comments below:
Christian W. Damus escribió:
> Hi, Adolfo,
>
> Find some replies in-line, below.
>
> Cheers,
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> The following Error obtained from my test cases:
>>
>> Validator-ERROR in org.eclipse.emf.ecore.model; IfExp.qvto:1 : The
>> instance type name 'null' is not well formed
>>
>> After debugging it (the info is not clear enough), the error is arisen
>> due to CollectionTypeImpl doesn't have an instance class established in
>> the same way as the remaining collections have.
>>
>> Suggestions
>>
>> 1. In CollectionTypleImpl add the missing
>> setInstanceClass(java.util.Collection.class) to each constructor ->
>> bugzilla
>
> The subclasses of CollectionTypeImpl set "concrete" instance classes. OCL
> should never create instances of collection types, but only its concrete
> subtypes. So, I don't expect that this would ever cause problems, but I
> guess there's no harm in setting the instance class. Please, do raise an
> enhancement request.
I think that I don't follow you:
OCL Abstract Syntax allows CollectionTypes (it's not abstract in
OCL.ecore, and obviously in OCLEcore.ecore neither)
OCL Concrete Sytanx allows creating CollectionTypes via
CollectionLiteralExpCS (in EssentialOCL.g)
Why do you say that "OCL should never create instances of collection
types" ?
Anyway the EValidator complains for every CollectionType instance.
Setting the instance class for it could be an option.
Another one could be overwriting the WellFormedInstanceTypeName
constraint for CollectionType in the OCL EValidator.
>
>
>> 2. What about suggesting EMF to include more information reported by the
>> EClassifier::WellFormedInstanceTypeName constraint, such us including
>> the name of classifier ?
>
> Well, I suppose, technically, the name would be redundant, as
> double-clicking the problem marker will select the problem element in the
> editor. However, it would be nice to see this information at a glance in
> the Problems view. Sounds like a good enhancement request for EMF.
>
Well my test cases throw errors in the console, so no chance for markers
:(.
So I'll ask in the EMF newsgroup.
Cheers,
Adolfo.
>
>> Regards,
>> Adolfo.
>
|
|
|
| Re: OCL Validator error. [message #54007 is a reply to message #53998] |
Thu, 17 April 2008 13:27 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
Section 8.2 of the OCL spec defines CollectionType as an abstract metatype.
However, this doesn't make sense, because it is clear from the concrete
syntax that it is possible to declare typed elements such as variables and
parameters as having type Collection(<some-type>). Moreover, there would
be no point in defining the Collection(T) data in the standard library if
CollectionType were abstract, because it could not exist. Therefore, MDT
OCL implements CollectionType as non-abstract (its abstractness is an error
in the spec).
What does make sense is the definition in section 11.6.1 of Collection(T) as
an abstract data type. Although the CollectionType metaclass is not
abstract, its instances (Collection data types) are. That is why I
indicated that the Collection type cannot be instantiated in OCL as Set,
Sequence, etc. can. However, this is also why that remark had no relevance
to your particular problem :-) Sorry for the confusion.
Cheers,
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
>
> Some in-lined comments below:
>
> Christian W. Damus escribió:
>> Hi, Adolfo,
>>
>> Find some replies in-line, below.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Adolfo Sánchez-Barbudo Herrera wrote:
>>
>>> The following Error obtained from my test cases:
>>>
>>> Validator-ERROR in org.eclipse.emf.ecore.model; IfExp.qvto:1 : The
>>> instance type name 'null' is not well formed
>>>
>>> After debugging it (the info is not clear enough), the error is arisen
>>> due to CollectionTypeImpl doesn't have an instance class established in
>>> the same way as the remaining collections have.
>>>
>>> Suggestions
>>>
>>> 1. In CollectionTypleImpl add the missing
>>> setInstanceClass(java.util.Collection.class) to each constructor ->
>>> bugzilla
>>
>> The subclasses of CollectionTypeImpl set "concrete" instance classes.
>> OCL should never create instances of collection types, but only its
>> concrete
>> subtypes. So, I don't expect that this would ever cause problems, but I
>> guess there's no harm in setting the instance class. Please, do raise an
>> enhancement request.
>
> I think that I don't follow you:
> OCL Abstract Syntax allows CollectionTypes (it's not abstract in
> OCL.ecore, and obviously in OCLEcore.ecore neither)
> OCL Concrete Sytanx allows creating CollectionTypes via
> CollectionLiteralExpCS (in EssentialOCL.g)
>
> Why do you say that "OCL should never create instances of collection
> types" ?
>
> Anyway the EValidator complains for every CollectionType instance.
> Setting the instance class for it could be an option.
> Another one could be overwriting the WellFormedInstanceTypeName
> constraint for CollectionType in the OCL EValidator.
>
>>
>>
>>> 2. What about suggesting EMF to include more information reported by the
>>> EClassifier::WellFormedInstanceTypeName constraint, such us including
>>> the name of classifier ?
>>
>> Well, I suppose, technically, the name would be redundant, as
>> double-clicking the problem marker will select the problem element in the
>> editor. However, it would be nice to see this information at a glance in
>> the Problems view. Sounds like a good enhancement request for EMF.
>>
>
> Well my test cases throw errors in the console, so no chance for markers
> :(.
>
> So I'll ask in the EMF newsgroup.
>
> Cheers,
> Adolfo.
>
>
>>
>>> Regards,
>>> Adolfo.
>>
|
|
|
| Re: OCL Validator error. [message #54017 is a reply to message #54007] |
Thu, 17 April 2008 14:33 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Ok Christian,
Thank you for the aclaration...
However, I think it's very related with my problem, and probably with
something that it's not very clear...Let's see some personal conclusions
Firstly, what I understand from 11.6.1 is that the generic collection
data type is abstract (and it is base class for every collection type IN
the standard library => generic set/bag/sequence/orderedSet data types),
however I must not conclude that every instance of CollectionType
Metatype must be abstract as well. Therefore, having a Collection(Class)
for example could be understood as a valid collection data type. I don't
control OCL specification, and maybe another point could contradict this
afirmation.
Secondly, if you understand that every instance of the (MetaClass)
CollectionType has to be an "abstract" type (which would need any kind
of subtype as Set,Bag,etc), CollectionLiteralExps using the Collection
Keyword would not make any sense. and it should be an error this kind of
literal expressions: Collection {1 ,2 ,3 ,4 }, however:
1. Is not noticed in the CST construction.
2. Is not noticed in the AST construction.
3. I don't know if there is any extra kind of later validation which
could notice it and I'm missing it. But what I'm sure is that my parser
which extends OCL CST and AST construction, and now EValidator, allows
me to create this kind of literal expressions.
BTW: What do you think about an "abstract" data type, it sounds horrible
ahahahaha ;P
What do you think about these conclusions ?
Cheers,
Adolfo.
Christian W. Damus escribió:
> Hi, Adolfo,
>
> Section 8.2 of the OCL spec defines CollectionType as an abstract metatype.
> However, this doesn't make sense, because it is clear from the concrete
> syntax that it is possible to declare typed elements such as variables and
> parameters as having type Collection(<some-type>). Moreover, there would
> be no point in defining the Collection(T) data in the standard library if
> CollectionType were abstract, because it could not exist. Therefore, MDT
> OCL implements CollectionType as non-abstract (its abstractness is an error
> in the spec).
>
> What does make sense is the definition in section 11.6.1 of Collection(T) as
> an abstract data type. Although the CollectionType metaclass is not
> abstract, its instances (Collection data types) are. That is why I
> indicated that the Collection type cannot be instantiated in OCL as Set,
> Sequence, etc. can. However, this is also why that remark had no relevance
> to your particular problem :-) Sorry for the confusion.
>
> Cheers,
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Some in-lined comments below:
>>
>> Christian W. Damus escribió:
>>> Hi, Adolfo,
>>>
>>> Find some replies in-line, below.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Adolfo Sánchez-Barbudo Herrera wrote:
>>>
>>>> The following Error obtained from my test cases:
>>>>
>>>> Validator-ERROR in org.eclipse.emf.ecore.model; IfExp.qvto:1 : The
>>>> instance type name 'null' is not well formed
>>>>
>>>> After debugging it (the info is not clear enough), the error is arisen
>>>> due to CollectionTypeImpl doesn't have an instance class established in
>>>> the same way as the remaining collections have.
>>>>
>>>> Suggestions
>>>>
>>>> 1. In CollectionTypleImpl add the missing
>>>> setInstanceClass(java.util.Collection.class) to each constructor ->
>>>> bugzilla
>>> The subclasses of CollectionTypeImpl set "concrete" instance classes.
>>> OCL should never create instances of collection types, but only its
>>> concrete
>>> subtypes. So, I don't expect that this would ever cause problems, but I
>>> guess there's no harm in setting the instance class. Please, do raise an
>>> enhancement request.
>> I think that I don't follow you:
>> OCL Abstract Syntax allows CollectionTypes (it's not abstract in
>> OCL.ecore, and obviously in OCLEcore.ecore neither)
>> OCL Concrete Sytanx allows creating CollectionTypes via
>> CollectionLiteralExpCS (in EssentialOCL.g)
>>
>> Why do you say that "OCL should never create instances of collection
>> types" ?
>>
>> Anyway the EValidator complains for every CollectionType instance.
>> Setting the instance class for it could be an option.
>> Another one could be overwriting the WellFormedInstanceTypeName
>> constraint for CollectionType in the OCL EValidator.
>>
>>>
>>>> 2. What about suggesting EMF to include more information reported by the
>>>> EClassifier::WellFormedInstanceTypeName constraint, such us including
>>>> the name of classifier ?
>>> Well, I suppose, technically, the name would be redundant, as
>>> double-clicking the problem marker will select the problem element in the
>>> editor. However, it would be nice to see this information at a glance in
>>> the Problems view. Sounds like a good enhancement request for EMF.
>>>
>> Well my test cases throw errors in the console, so no chance for markers
>> :(.
>>
>> So I'll ask in the EMF newsgroup.
>>
>> Cheers,
>> Adolfo.
>>
>>
>>>> Regards,
>>>> Adolfo.
>
|
|
|
| Re: OCL Validator error. [message #54027 is a reply to message #54017] |
Thu, 17 April 2008 14:57 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
OMG !!!!!!
No errors showed in the console during in the parsing, but an exception
was thrown while persisting the output model !!!
java.lang.IllegalArgumentException: The value 'Collection' is not a
valid enumerator of 'CollectionKind'
at
org.eclipse.gmt.umlx.qvt.EssentialOCL.impl.EssentialOCLFacto ryImpl.createCollectionKindFromString(EssentialOCLFactoryImp l.java:507)
Definitely, it seems that Collection should not be used for
CollectionLiteralExps, and something is going wrong... If "Collection"
doesn't feel well to CollectionLiteralExp, probably the we should have
control in somewhere....
And looking into the metamodel again, I think that I finally have
discovered where is controlled... no_collection_instances is the clue,
isn't it ? :D
Well, I think that is sufficient for today...I don't want you to waste
your time more ;P
My unique doubt after all is if there is a part in the specification
which says that no collection data types may be used (I think that the
statement in the 11.6.1 is not sufficient)...Anyway, I'll try to
discover it in the OCL spec.
Cheers !!!
Adolfo.
Adolfo Sánchez-Barbudo Herrera escribió:
> Ok Christian,
>
> Thank you for the aclaration...
>
> However, I think it's very related with my problem, and probably with
> something that it's not very clear...Let's see some personal conclusions
>
> Firstly, what I understand from 11.6.1 is that the generic collection
> data type is abstract (and it is base class for every collection type IN
> the standard library => generic set/bag/sequence/orderedSet data types),
> however I must not conclude that every instance of CollectionType
> Metatype must be abstract as well. Therefore, having a Collection(Class)
> for example could be understood as a valid collection data type. I don't
> control OCL specification, and maybe another point could contradict this
> afirmation.
>
> Secondly, if you understand that every instance of the (MetaClass)
> CollectionType has to be an "abstract" type (which would need any kind
> of subtype as Set,Bag,etc), CollectionLiteralExps using the Collection
> Keyword would not make any sense. and it should be an error this kind of
> literal expressions: Collection {1 ,2 ,3 ,4 }, however:
> 1. Is not noticed in the CST construction.
> 2. Is not noticed in the AST construction.
> 3. I don't know if there is any extra kind of later validation which
> could notice it and I'm missing it. But what I'm sure is that my parser
> which extends OCL CST and AST construction, and now EValidator, allows
> me to create this kind of literal expressions.
>
> BTW: What do you think about an "abstract" data type, it sounds horrible
> ahahahaha ;P
>
> What do you think about these conclusions ?
>
> Cheers,
> Adolfo.
>
> Christian W. Damus escribió:
>> Hi, Adolfo,
>>
>> Section 8.2 of the OCL spec defines CollectionType as an abstract
>> metatype. However, this doesn't make sense, because it is clear from
>> the concrete
>> syntax that it is possible to declare typed elements such as variables
>> and
>> parameters as having type Collection(<some-type>). Moreover, there would
>> be no point in defining the Collection(T) data in the standard library if
>> CollectionType were abstract, because it could not exist. Therefore, MDT
>> OCL implements CollectionType as non-abstract (its abstractness is an
>> error
>> in the spec).
>>
>> What does make sense is the definition in section 11.6.1 of
>> Collection(T) as
>> an abstract data type. Although the CollectionType metaclass is not
>> abstract, its instances (Collection data types) are. That is why I
>> indicated that the Collection type cannot be instantiated in OCL as Set,
>> Sequence, etc. can. However, this is also why that remark had no
>> relevance
>> to your particular problem :-) Sorry for the confusion.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Adolfo Sánchez-Barbudo Herrera wrote:
>>
>>> Hi Christian,
>>>
>>> Some in-lined comments below:
>>>
>>> Christian W. Damus escribió:
>>>> Hi, Adolfo,
>>>>
>>>> Find some replies in-line, below.
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Adolfo Sánchez-Barbudo Herrera wrote:
>>>>
>>>>> The following Error obtained from my test cases:
>>>>>
>>>>> Validator-ERROR in org.eclipse.emf.ecore.model; IfExp.qvto:1 : The
>>>>> instance type name 'null' is not well formed
>>>>>
>>>>> After debugging it (the info is not clear enough), the error is arisen
>>>>> due to CollectionTypeImpl doesn't have an instance class
>>>>> established in
>>>>> the same way as the remaining collections have.
>>>>>
>>>>> Suggestions
>>>>>
>>>>> 1. In CollectionTypleImpl add the missing
>>>>> setInstanceClass(java.util.Collection.class) to each constructor ->
>>>>> bugzilla
>>>> The subclasses of CollectionTypeImpl set "concrete" instance
>>>> classes. OCL should never create instances of collection types, but
>>>> only its
>>>> concrete
>>>> subtypes. So, I don't expect that this would ever cause problems,
>>>> but I
>>>> guess there's no harm in setting the instance class. Please, do
>>>> raise an
>>>> enhancement request.
>>> I think that I don't follow you:
>>> OCL Abstract Syntax allows CollectionTypes (it's not abstract in
>>> OCL.ecore, and obviously in OCLEcore.ecore neither)
>>> OCL Concrete Sytanx allows creating CollectionTypes via
>>> CollectionLiteralExpCS (in EssentialOCL.g)
>>>
>>> Why do you say that "OCL should never create instances of collection
>>> types" ?
>>>
>>> Anyway the EValidator complains for every CollectionType instance.
>>> Setting the instance class for it could be an option.
>>> Another one could be overwriting the WellFormedInstanceTypeName
>>> constraint for CollectionType in the OCL EValidator.
>>>
>>>>
>>>>> 2. What about suggesting EMF to include more information reported
>>>>> by the
>>>>> EClassifier::WellFormedInstanceTypeName constraint, such us including
>>>>> the name of classifier ?
>>>> Well, I suppose, technically, the name would be redundant, as
>>>> double-clicking the problem marker will select the problem element
>>>> in the
>>>> editor. However, it would be nice to see this information at a
>>>> glance in
>>>> the Problems view. Sounds like a good enhancement request for EMF.
>>>>
>>> Well my test cases throw errors in the console, so no chance for markers
>>> :(.
>>>
>>> So I'll ask in the EMF newsgroup.
>>>
>>> Cheers,
>>> Adolfo.
>>>
>>>
>>>>> Regards,
>>>>> Adolfo.
>>
|
|
|
| Re: OCL Validator error. [message #54036 is a reply to message #54027] |
Thu, 17 April 2008 15:23 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
Are you taking the Object Management Group's name in vain? ;-)
On a more serious note: the discussion of the collection types in section
11.6 makes it clear that the standard library type Collection(T) is a
template, as are its subtype Set(T), Sequence(T), and Bag(T) (OrderedSet(T)
is a subtype of Set(T)). Thus, there is one template definition of
Collection(T) and it is abstract. Bindings of the template for different
substitutions of T do not change its abstractness.
Probably, the parser should be more friendly in the validation of
Collection{...} literals, not leaving it to some back-end validation step
to complain about them. Yes, no_collection_instances is important for
validation of AST generated not from text, but the parser could also check
this.
Cheers,
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> OMG !!!!!!
>
> No errors showed in the console during in the parsing, but an exception
> was thrown while persisting the output model !!!
>
> java.lang.IllegalArgumentException: The value 'Collection' is not a
> valid enumerator of 'CollectionKind'
> at
>
org.eclipse.gmt.umlx.qvt.EssentialOCL.impl.EssentialOCLFacto ryImpl.createCollectionKindFromString(EssentialOCLFactoryImp l.java:507)
>
>
> Definitely, it seems that Collection should not be used for
> CollectionLiteralExps, and something is going wrong... If "Collection"
> doesn't feel well to CollectionLiteralExp, probably the we should have
> control in somewhere....
>
> And looking into the metamodel again, I think that I finally have
> discovered where is controlled... no_collection_instances is the clue,
> isn't it ? :D
>
> Well, I think that is sufficient for today...I don't want you to waste
> your time more ;P
>
> My unique doubt after all is if there is a part in the specification
> which says that no collection data types may be used (I think that the
> statement in the 11.6.1 is not sufficient)...Anyway, I'll try to
> discover it in the OCL spec.
>
> Cheers !!!
> Adolfo.
>
> Adolfo Sánchez-Barbudo Herrera escribió:
>> Ok Christian,
>>
>> Thank you for the aclaration...
>>
>> However, I think it's very related with my problem, and probably with
>> something that it's not very clear...Let's see some personal conclusions
>>
>> Firstly, what I understand from 11.6.1 is that the generic collection
>> data type is abstract (and it is base class for every collection type IN
>> the standard library => generic set/bag/sequence/orderedSet data types),
>> however I must not conclude that every instance of CollectionType
>> Metatype must be abstract as well. Therefore, having a Collection(Class)
>> for example could be understood as a valid collection data type. I don't
>> control OCL specification, and maybe another point could contradict this
>> afirmation.
>>
>> Secondly, if you understand that every instance of the (MetaClass)
>> CollectionType has to be an "abstract" type (which would need any kind
>> of subtype as Set,Bag,etc), CollectionLiteralExps using the Collection
>> Keyword would not make any sense. and it should be an error this kind of
>> literal expressions: Collection {1 ,2 ,3 ,4 }, however:
>> 1. Is not noticed in the CST construction.
>> 2. Is not noticed in the AST construction.
>> 3. I don't know if there is any extra kind of later validation which
>> could notice it and I'm missing it. But what I'm sure is that my parser
>> which extends OCL CST and AST construction, and now EValidator, allows
>> me to create this kind of literal expressions.
>>
>> BTW: What do you think about an "abstract" data type, it sounds horrible
>> ahahahaha ;P
>>
>> What do you think about these conclusions ?
>>
>> Cheers,
>> Adolfo.
-----8<-----
|
|
|
| Re: OCL Validator error. [message #54055 is a reply to message #54036] |
Thu, 17 April 2008 15:58 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
More comments
Christian W. Damus escribió:
> Hi, Adolfo,
>
> Are you taking the Object Management Group's name in vain? ;-)
Hahahahahaha... I'll have to start to use a new variant in Eclipse
newsgroup!!!! ... What about OhMG xD
>
> On a more serious note: the discussion of the collection types in section
> 11.6 makes it clear that the standard library type Collection(T) is a
> template, as are its subtype Set(T), Sequence(T), and Bag(T) (OrderedSet(T)
> is a subtype of Set(T)). Thus, there is one template definition of
> Collection(T) and it is abstract. Bindings of the template for different
> substitutions of T do not change its abstractness.
Definitely the types, metatypes, datatypes, their bindings, and the
family of all of them have overcome me today. I need a deep thought
about this, but It won't surely now.... ¬¬!!
Besides, in QVTo we have a far parent of them: TemplateParameterType...
I'm so lucky :D :D :D ..... ¬¬!!.... Fortunately I'm seeing the light at
the end of tunnel :)
>
> Probably, the parser should be more friendly in the validation of
> Collection{...} literals, not leaving it to some back-end validation step
> to complain about them. Yes, no_collection_instances is important for
> validation of AST generated not from text, but the parser could also check
> this.
I see...Well the important is that is checked in somewhere... And I have
find out that I have missed some validation in my parsing process. I
just need to look into how to integrate it ...
About the creation of Collection(Something) in the output models... who
knows... We will see here (newsgroup) with new conclusions ;)....
Fortunately we have its "brother" A.K.A Java which will surely help me
with them ;P.
Cheers,
Adolfo.
>
> Cheers,
>
> Christian
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> OMG !!!!!!
>>
>> No errors showed in the console during in the parsing, but an exception
>> was thrown while persisting the output model !!!
>>
>> java.lang.IllegalArgumentException: The value 'Collection' is not a
>> valid enumerator of 'CollectionKind'
>> at
>>
> org.eclipse.gmt.umlx.qvt.EssentialOCL.impl.EssentialOCLFacto ryImpl.createCollectionKindFromString(EssentialOCLFactoryImp l.java:507)
>>
>> Definitely, it seems that Collection should not be used for
>> CollectionLiteralExps, and something is going wrong... If "Collection"
>> doesn't feel well to CollectionLiteralExp, probably the we should have
>> control in somewhere....
>>
>> And looking into the metamodel again, I think that I finally have
>> discovered where is controlled... no_collection_instances is the clue,
>> isn't it ? :D
>>
>> Well, I think that is sufficient for today...I don't want you to waste
>> your time more ;P
>>
>> My unique doubt after all is if there is a part in the specification
>> which says that no collection data types may be used (I think that the
>> statement in the 11.6.1 is not sufficient)...Anyway, I'll try to
>> discover it in the OCL spec.
>>
>> Cheers !!!
>> Adolfo.
>>
>> Adolfo Sánchez-Barbudo Herrera escribió:
>>> Ok Christian,
>>>
>>> Thank you for the aclaration...
>>>
>>> However, I think it's very related with my problem, and probably with
>>> something that it's not very clear...Let's see some personal conclusions
>>>
>>> Firstly, what I understand from 11.6.1 is that the generic collection
>>> data type is abstract (and it is base class for every collection type IN
>>> the standard library => generic set/bag/sequence/orderedSet data types),
>>> however I must not conclude that every instance of CollectionType
>>> Metatype must be abstract as well. Therefore, having a Collection(Class)
>>> for example could be understood as a valid collection data type. I don't
>>> control OCL specification, and maybe another point could contradict this
>>> afirmation.
>>>
>>> Secondly, if you understand that every instance of the (MetaClass)
>>> CollectionType has to be an "abstract" type (which would need any kind
>>> of subtype as Set,Bag,etc), CollectionLiteralExps using the Collection
>>> Keyword would not make any sense. and it should be an error this kind of
>>> literal expressions: Collection {1 ,2 ,3 ,4 }, however:
>>> 1. Is not noticed in the CST construction.
>>> 2. Is not noticed in the AST construction.
>>> 3. I don't know if there is any extra kind of later validation which
>>> could notice it and I'm missing it. But what I'm sure is that my parser
>>> which extends OCL CST and AST construction, and now EValidator, allows
>>> me to create this kind of literal expressions.
>>>
>>> BTW: What do you think about an "abstract" data type, it sounds horrible
>>> ahahahaha ;P
>>>
>>> What do you think about these conclusions ?
>>>
>>> Cheers,
>>> Adolfo.
>
> -----8<-----
|
|
|
Goto Forum:
Current Time: Fri Apr 26 23:37:54 GMT 2024
Powered by FUDForum. Page generated in 0.03718 seconds |
] 
Search
Help
Register
Login
Home
