Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvtd-dev] [Dev] binding.isLoop for collections

Hi Ed,

 

In the qvti package of uk.ac.york.qvtd.tests.hhr project you can find the collection type attribute case in HSVtoHLS.qvti :

 

map HSV2MiddleRecursion {                      -- recursive call to visit children

                hsvNode := hsvRoot.children;                    -- children is a collection type attribute (one to many)

                middleParent := middleRoot;

}

 

In the file Graph2GraphHierarchical.qvti, you can find the select case:

 

map Node2Middle {

n1 := g1.element->select(e | e.oclIsTypeOf(simplegraph::Node));

                middleParent := middleG2G;

}

 

 

The binding.isIsLoop() method is invoked as part of the mapping visit in the new visitMappingCall recursive implementation (QVTimperativeAbstractEvaluationVisitor.java).

 

 

Regards,

 

 

Horacio Hoyos Rodríguez

EngD Student

University of York

 

http://www.york.ac.uk/docs/disclaimer/email.htm

 

From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: 15 April 2013 16:47
To: QVTD developers mailing list
Subject: Re: [qvtd-dev] [Dev] binding.isLoop for collections

 

Hi

I'm baffled because what you describe bears no resemblance to my recollection of the code.

Give me some line numbers.

    Regards

        Ed

On 15/04/2013 16:04, Horacio Hoyos Rodriguez wrote:

Hi Ed,

 

I guess my problem reduces to understanding how binding.isIsLoop() method works. Why for package.elements (collection type attribute) isIsLoop() returns true, but for x->select()  it does not, if the result of evaluating both statements is a collection. If this behaviour is correct, I don’t understand why, statically, the depth of a collection type attribute is different from the depth of a select/collect statement. And if so, if this means that for CallMappings multi-value attributes are only allowed in the form of collection type attributes, I think it will impose a very limiting restriction on QVTi.

 

Regards,

 

 

Horacio Hoyos Rodríguez

EngD Student

University of York

 

http://www.york.ac.uk/docs/disclaimer/email.htm

 

From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: 15 April 2013 13:23
To: QVTD developers mailing list
Subject: Re: [qvtd-dev] [Dev] binding.isLoop for collections

 

Hi

I'm not sure that I understand your problem. Perhaps you assume that the minimum depth of a Collection is one. I meant to include a non-collection as a Collection of depth 0.

    Regards

        Ed

On 15/04/2013 13:07, Horacio Hoyos Rodriguez wrote:

Hi Ed,

 

I understand your point and the differences in the two types of bindings. Is it correct to assume that binding.isIsLoop() follows this logic? If so, my previous example indicates a bug.  If on the other hand what this is implying is that the semantics is constrained to only allow bindings in the form of (BNF):

 

variable “:=” SlotOwnerOCLExpr”.”PropertyName

 

where Property is a collection, I think it should be changed to support the more general case.

 

 

Regards,

 

Horacio Hoyos Rodríguez

EngD Student

University of York

 

http://www.york.ac.uk/docs/disclaimer/email.htm

 

From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: 15 April 2013 12:49
To: QVTD developers mailing list
Subject: Re: [qvtd-dev] [Dev] binding.isLoop for collections

 

Hi

That is why the definition has been moved to the user syntax.

Consider a List(Set(String)) being passed to a Set(String) bound variable. The looping occurs over the List.
But a Set(String) passed to a Set(String) has no looping, despite being a collection value and a collection type everywhere.

It is therefore a requirement that a looped invocation provides a depth N+1 collection to be iterated by the depth N bound variable.

    Regards

        Ed


On 15/04/2013 12:20, Horacio Hoyos Rodriguez wrote:

Hi Ed,

 

What is the precise definition of a binding being a loop? It seems the current implementation tests if the ValueOCLExpr refers to an attribute that is a collection, rather than testing if the result of evaluating the ValueOCLExpr returns a collection. Thus in the following example binding.isIsLoop() returns false, although the result of the ValueOCLExpr is a collection:

 

map Node2Middle {

                n1 := g1.element->select(e | e.oclIsTypeOf(simplegraph::Node));

                middleParent := middleG2G;

    }

 

Regards ,

 

 

Horacio Hoyos Rodríguez

EngD Student

University of York

 

http://www.york.ac.uk/docs/disclaimer/email.htm

 

 

_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev

 

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6245 - Release Date: 04/14/13

 



_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6245 - Release Date: 04/14/13

 




_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev




No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6245 - Release Date: 04/14/13

 

Back to the top