[furcas-discussion] foreach / when

[Uhl, Axel]

Hi all,

when implementing the foreach model updater I was somehow implicitly assuming that the when-clauses use the result of the foreach-expression as their self-context. However, it turns out that the implementation in DelayedReferenceHelper uses the template's element as self-context for both, the foreach-expression and all when-expressions. Checking back with Class.tcs confirms this. Example:

                        ownedTypeDefinition = foreach("OCL:self.getSignature().output",  
                                when="OCL:self.getSignature().output.isMany() and self.calledBlock.getType().isMany()", mode="functionCallExpression", as=NestedTypeDefinition,
                                when="OCL:self.getSignature().output.oclIsKindOf(ClassTypeDefinition)", mode="functionCallExpression", as=ClassTypeDefinition, 
                                when="OCL:self.getSignature().output.oclIsKindOf(FunctionSignatureTypeDefinition)", mode="functionCallExpression", as=FunctionSignatureTypeDefinition,
                                when="OCL:self.getSignature().output.oclIsKindOf(NestedTypeDefinition)", mode="functionCallExpressionNoFurtherNesting", as=NestedTypeDefinition)

While this works for a foreach-expression that delivers a single-multiplicity element, it's unclear to me how this is supposed to work for a many-multiplicity. I was trying the following example for a test case:

		     revenues=foreach("OCL:self.articles",
		                      when="self.key.size() < 5", mode=short, as=RevenueLedger,
		                      when="self.key.size() >= 5 and self.key.size() < 10", mode=medium, as=RevenueLedger,
		                      mode=long, as=RevenueLedger)

The property init is being used in a template for type Author, while self.articles obviously produces a Set(Article).

The documentation at http://www.furcas.org/wiki/index.php/Define_Language#PredicatePropertyInits remains vague and doesn't even specify what the context object for the when-clauses is.

With only a single context element, the Class.tcs example would be hard to do in case the context for the when-clause were the result of the foreach expression. It would just be a bit hard to navigate backwards through the getSignature() operation call. On the other hand, I would expect that usually the selection performed by a when-clause would be specific to the individual result elements produced by the foreach-expression. That would be an indication that the results of the foreach should be used as context objects for the when clauses.

Talking about implementation complexity, having the same context for when and foreach also has advantages. When the impact on a when-clause has been traced back this is (give or take the use of #context) the element to update and the context for the foreach expression.

What's your opinion on all of this?

Best,
-- Axel