Loop Shape “demystified”

In orchestration design I think that the loop shape is often misunderstood and misused and is the cause of a lot of unnecessarily complex orchestrations I saw.

Even the shape definition is ambiguous:

You can use the Loop shape to repeat actions in a continuous loop, as long as some condition is met.

The key point is that, differently from C#, XLANG language has neither for cycle nor do-while, the only XLANG construct available is the C# while-do equivalent: the loop shape.

A lot of people try to implement for cycles using loop shapes and this is simply wrong. Think about it: if for loop was banned from C# you would try to recreate it using while or would search for problem solutions which naturally blend to while instead of for loop?

I’m totally for the second option: model your problem in terms of language constraints you have, don’t try to fight against the language to better fit your model.

For what?

Let’s make an example of this mismatch, and imagine we want to implement our for loop in an orchestration:

1. We need a variable to keep the counter (the classical i)
2. We need a variable to keep the maximum (if we don’t want to cable it directly in an expression)
3. We need an expression to do things with i variable
4. We need an expression to increase the counter.
5. An (optional) expression to check termination ( i==max ) 
6. An (optional) boolean variable to keep termination condition.

This bring us to ask ourselves other (totally out of context) questions:

1. Counter must be increased entering the iteration or exiting?
2. Exit condition must be evaluated entering on exiting the iteration?

In a for loop these questions are obvious but remember we don’t have a for loop in XLANG, we’re just faking it…

So, till now we have declared two or three variables in our orchestration, we’ve placed two or three expression shapes in our loop, we’re posing ourselves a couple of confused questions and the worse thing is that all these overhead is infrastructural, have you noticed that we’ve not talked at all business requirements?

In the meanWHILE…

When we realize that loop shape is a while everything will became simple and natural:

1. We need a function to tell us if while must continue or not .
2. A function to iterate to the next element.
3. A function to return current element.

An object with these characteristics is well known in informatics and in C# it is represented by an interface: System.Collections.IEnumerator (it exists also a generic version but since XLANG doesn’t support generics we’re stuck with non generic version).

Interface has 2 methods and one property:

bool MoveNext()	Include first two functions of the above list: move to the next element if it exists and return true, false otherwise
Object Current	Returns the current element (third function)
void Reset()	Reset the enumerator.

With an IEnumerator our loop will become trivial to write:

and the same (to show equivalence) written in C#

   1: while(enumerator.MoveNext())

   2: {

   3:   //Use enumerator.Current

   4: }

A single variable, implementing a standard .NET interface and we’ve three advantages:

1. we’re using a single variable in the orchestration.
2. we’ve moved infrastructure logic outside of orchestration.
3. we’re  simplifying and making more readable our orchestration.