Eclipse Community Forums: Epsilon » Problem resolving object slots from ECL

Help

Home

Home » Modeling » Epsilon » Problem resolving object slots from ECL

Show: Today's Messages :: Show Polls :: Message Navigator

Problem resolving object slots from ECL [message #526864]

Tue, 13 April 2010 10:44

Eclipse User

Originally posted by: c.k.holmes.lboro.ac.uk

Hi,
I have an increasingly refined model structure of the form:
Project A
Package A1
Package A2
Where Package A2 has a 'ref' relationship to a class defined in Package
A1 (I suspect this detail is irrelevant to this query).

Project B
Package B1
Although Package B1 actually comprises a nested hierarchy of packages it
extends some of the concepts introduced in Package A2.

Package A2 comprises a tree structured hierarchy of classes (the
examples below are contrived):
class Catalogue {
attr String name = "";
val Component[*] contains;
}
class Component {
attr String name = "";
val SubComponent[*] contains;
}
class SubComponent {
attr String name = "";
}

Package B1 comprises:
class Specification extends A2.Catalogue {
<more attributes>
}
class SpecifiedSubComponent extends A2.SubComponent {
<more attributes>
}

I want to compare two instances of the same metamodel. My ECL looks like
this:
pre {
}
post {
}
rule Specification
match left : Left!Specification
with right : Right!Specification {
compare {
return left.name = right.name;
}
do {
if(LoggingEnabled) {
('specification matched on: ' + left.name).println();
}
}
}
rule Component
match left : Left!Component
with right : Right!Component {
compare {
return left.name = right.name;
}
do {
if(LoggingEnabled) {
('component matched on: ' + left.name).println();
}
}
}
rule SpecifiedSubComponent
match left : Left!SpecifiedSubComponent
with right : Right!SpecifiedSubComponent {
compare {
return left.name = right.name;
}
do {
if(LoggingEnabled) {
('specified sub-component matched on: ' + left.name).println();
}
}
}

The ECL reports a failure at the compare statement block for the rule
Component, stating that property 'name' can't be found in class
Component. However the logging trace shows that the message:
'component matched on: aComponnetName' has been ejected to the console,
hence it has resolved the name attribute of the 'left' object (I can
switch left and right objects, it makes no difference).
If I remove rule Component then the ECL runs to completion without
raising an exception.

I can't see an error in my ECL, and my suspicion is that there is
something awry in the way ECL is dealing with the model hierarchy. I am
running the ECL from an Ant script.

Regards
Chris

Report message to a moderator

Re: Problem resolving object slots from ECL [message #526866 is a reply to message #526864]

Tue, 13 April 2010 10:49

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi Chris,

Could you please put together a minimal example that reproduces this
behaviour and send it to me by email so that I can have closer look?

Cheers,
Dimitris

On 13/04/2010 13:44, Chris Holmes wrote:
> Hi,
> I have an increasingly refined model structure of the form:
> Project A
> Package A1
> Package A2
> Where Package A2 has a 'ref' relationship to a class defined in Package
> A1 (I suspect this detail is irrelevant to this query).
>
> Project B
> Package B1
> Although Package B1 actually comprises a nested hierarchy of packages it
> extends some of the concepts introduced in Package A2.
>
> Package A2 comprises a tree structured hierarchy of classes (the
> examples below are contrived):
> class Catalogue {
> attr String name = "";
> val Component[*] contains;
> }
> class Component {
> attr String name = "";
> val SubComponent[*] contains;
> }
> class SubComponent {
> attr String name = "";
> }
>
> Package B1 comprises:
> class Specification extends A2.Catalogue {
> <more attributes>
> }
> class SpecifiedSubComponent extends A2.SubComponent {
> <more attributes>
> }
>
> I want to compare two instances of the same metamodel. My ECL looks like
> this:
> pre {
> }
> post {
> }
> rule Specification
> match left : Left!Specification
> with right : Right!Specification {
> compare {
> return left.name = right.name;
> }
> do {
> if(LoggingEnabled) {
> ('specification matched on: ' + left.name).println();
> }
> }
> }
> rule Component
> match left : Left!Component
> with right : Right!Component {
> compare {
> return left.name = right.name;
> }
> do {
> if(LoggingEnabled) {
> ('component matched on: ' + left.name).println();
> }
> }
> }
> rule SpecifiedSubComponent
> match left : Left!SpecifiedSubComponent
> with right : Right!SpecifiedSubComponent {
> compare {
> return left.name = right.name;
> }
> do {
> if(LoggingEnabled) {
> ('specified sub-component matched on: ' + left.name).println();
> }
> }
> }
>
> The ECL reports a failure at the compare statement block for the rule
> Component, stating that property 'name' can't be found in class
> Component. However the logging trace shows that the message:
> 'component matched on: aComponnetName' has been ejected to the console,
> hence it has resolved the name attribute of the 'left' object (I can
> switch left and right objects, it makes no difference).
> If I remove rule Component then the ECL runs to completion without
> raising an exception.
>
> I can't see an error in my ECL, and my suspicion is that there is
> something awry in the way ECL is dealing with the model hierarchy. I am
> running the ECL from an Ant script.
>
> Regards
> Chris

Report message to a moderator

Re: Problem resolving object slots from ECL [message #526928 is a reply to message #526866]

Tue, 13 April 2010 14:06

Eclipse User

Originally posted by: c.k.holmes.lboro.ac.uk

Hi Dimitris,
I'm not sure that such a minimal example is such a small undertaking
(for me!;)). I have amended my metamodel such that I have a new class
'SpecifiedComponent' in package B1 extending from 'Component' in package
A2, and the ECL now executes to completion. Hence, I assume that the
problem is something to do with ECL acquiring the appropriate package
level visibility of the components in the metamodel(s).

I can demonstrate the problem on the complete model set when I'm next in
York, currently planned to be Fri 30-Apr - will you be there?

Best Wishes
Chris

Dimitris Kolovos wrote:
> Hi Chris,
>
> Could you please put together a minimal example that reproduces this
> behaviour and send it to me by email so that I can have closer look?
>
> Cheers,
> Dimitris
>
> On 13/04/2010 13:44, Chris Holmes wrote:
>> Hi,
>> I have an increasingly refined model structure of the form:
>> Project A
>> Package A1
>> Package A2
>> Where Package A2 has a 'ref' relationship to a class defined in Package
>> A1 (I suspect this detail is irrelevant to this query).
>>
>> Project B
>> Package B1
>> Although Package B1 actually comprises a nested hierarchy of packages it
>> extends some of the concepts introduced in Package A2.
>>
>> Package A2 comprises a tree structured hierarchy of classes (the
>> examples below are contrived):
>> class Catalogue {
>> attr String name = "";
>> val Component[*] contains;
>> }
>> class Component {
>> attr String name = "";
>> val SubComponent[*] contains;
>> }
>> class SubComponent {
>> attr String name = "";
>> }
>>
>> Package B1 comprises:
>> class Specification extends A2.Catalogue {
>> <more attributes>
>> }
>> class SpecifiedSubComponent extends A2.SubComponent {
>> <more attributes>
>> }
>>
>> I want to compare two instances of the same metamodel. My ECL looks like
>> this:
>> pre {
>> }
>> post {
>> }
>> rule Specification
>> match left : Left!Specification
>> with right : Right!Specification {
>> compare {
>> return left.name = right.name;
>> }
>> do {
>> if(LoggingEnabled) {
>> ('specification matched on: ' + left.name).println();
>> }
>> }
>> }
>> rule Component
>> match left : Left!Component
>> with right : Right!Component {
>> compare {
>> return left.name = right.name;
>> }
>> do {
>> if(LoggingEnabled) {
>> ('component matched on: ' + left.name).println();
>> }
>> }
>> }
>> rule SpecifiedSubComponent
>> match left : Left!SpecifiedSubComponent
>> with right : Right!SpecifiedSubComponent {
>> compare {
>> return left.name = right.name;
>> }
>> do {
>> if(LoggingEnabled) {
>> ('specified sub-component matched on: ' + left.name).println();
>> }
>> }
>> }
>>
>> The ECL reports a failure at the compare statement block for the rule
>> Component, stating that property 'name' can't be found in class
>> Component. However the logging trace shows that the message:
>> 'component matched on: aComponnetName' has been ejected to the console,
>> hence it has resolved the name attribute of the 'left' object (I can
>> switch left and right objects, it makes no difference).
>> If I remove rule Component then the ECL runs to completion without
>> raising an exception.
>>
>> I can't see an error in my ECL, and my suspicion is that there is
>> something awry in the way ECL is dealing with the model hierarchy. I am
>> running the ECL from an Ant script.
>>
>> Regards
>> Chris
>

Report message to a moderator

Re: Problem resolving object slots from ECL [message #527046 is a reply to message #526928]

Tue, 13 April 2010 19:35

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi Chris,

Pleas see comments below:

On 13/04/2010 17:06, Chris Holmes wrote:
> Hi Dimitris,
> I'm not sure that such a minimal example is such a small undertaking
> (for me!;)). I have amended my metamodel such that I have a new class
> 'SpecifiedComponent' in package B1 extending from 'Component' in package
> A2, and the ECL now executes to completion. Hence, I assume that the
> problem is something to do with ECL acquiring the appropriate package
> level visibility of the components in the metamodel(s).

In case it helps, all languages in Epsilon reuse the same model
connectivity layer so the problem should be reproducible using plain EOL.

>
> I can demonstrate the problem on the complete model set when I'm next in
> York, currently planned to be Fri 30-Apr - will you be there?

Yes. Let's have a look at it then.

>
> Best Wishes
> Chris
>

Cheers,
Dimitris

> Dimitris Kolovos wrote:
>> Hi Chris,
>>
>> Could you please put together a minimal example that reproduces this
>> behaviour and send it to me by email so that I can have closer look?
>>
>> Cheers,
>> Dimitris
>>
>> On 13/04/2010 13:44, Chris Holmes wrote:
>>> Hi,
>>> I have an increasingly refined model structure of the form:
>>> Project A
>>> Package A1
>>> Package A2
>>> Where Package A2 has a 'ref' relationship to a class defined in Package
>>> A1 (I suspect this detail is irrelevant to this query).
>>>
>>> Project B
>>> Package B1
>>> Although Package B1 actually comprises a nested hierarchy of packages it
>>> extends some of the concepts introduced in Package A2.
>>>
>>> Package A2 comprises a tree structured hierarchy of classes (the
>>> examples below are contrived):
>>> class Catalogue {
>>> attr String name = "";
>>> val Component[*] contains;
>>> }
>>> class Component {
>>> attr String name = "";
>>> val SubComponent[*] contains;
>>> }
>>> class SubComponent {
>>> attr String name = "";
>>> }
>>>
>>> Package B1 comprises:
>>> class Specification extends A2.Catalogue {
>>> <more attributes>
>>> }
>>> class SpecifiedSubComponent extends A2.SubComponent {
>>> <more attributes>
>>> }
>>>
>>> I want to compare two instances of the same metamodel. My ECL looks like
>>> this:
>>> pre {
>>> }
>>> post {
>>> }
>>> rule Specification
>>> match left : Left!Specification
>>> with right : Right!Specification {
>>> compare {
>>> return left.name = right.name;
>>> }
>>> do {
>>> if(LoggingEnabled) {
>>> ('specification matched on: ' + left.name).println();
>>> }
>>> }
>>> }
>>> rule Component
>>> match left : Left!Component
>>> with right : Right!Component {
>>> compare {
>>> return left.name = right.name;
>>> }
>>> do {
>>> if(LoggingEnabled) {
>>> ('component matched on: ' + left.name).println();
>>> }
>>> }
>>> }
>>> rule SpecifiedSubComponent
>>> match left : Left!SpecifiedSubComponent
>>> with right : Right!SpecifiedSubComponent {
>>> compare {
>>> return left.name = right.name;
>>> }
>>> do {
>>> if(LoggingEnabled) {
>>> ('specified sub-component matched on: ' + left.name).println();
>>> }
>>> }
>>> }
>>>
>>> The ECL reports a failure at the compare statement block for the rule
>>> Component, stating that property 'name' can't be found in class
>>> Component. However the logging trace shows that the message:
>>> 'component matched on: aComponnetName' has been ejected to the console,
>>> hence it has resolved the name attribute of the 'left' object (I can
>>> switch left and right objects, it makes no difference).
>>> If I remove rule Component then the ECL runs to completion without
>>> raising an exception.
>>>
>>> I can't see an error in my ECL, and my suspicion is that there is
>>> something awry in the way ECL is dealing with the model hierarchy. I am
>>> running the ECL from an Ant script.
>>>
>>> Regards
>>> Chris
>>

Report message to a moderator