VIII.0.1.6 Iterators

.NET provides a standard interface that allows the writing of iterators on collections of different types. In FeResPost, all the iterators are based on two classes:

• The “Iterator” class that implements “IEnumerable” interface.
• The “IterX” class that implements “IEnumerator” interface.

As for the COM component, two classes devoted to iterations have been added because it does not seem possible to create a class that proposes several enumerators.

The “Iterator” class is common to all the iterators of all the FeResPost classes. But an Iterator object behaves differently depending on the class that produces it and/or the method of the class that is used to produce it.

Let us illustrate it by an example... Consider the “each_ply” iterator defined in ClaLam class of FeResPost ruby extension. With the ruby extension, the iteration on the plies of a laminate may be performed as follows:

With FeResPost .NET assembly and IronRuby, an Iterator must first be produced before iterating on the elements of the corresponding collection. This can be done as follows:

This examples illustrates the conventions that have been used when programming the FeResPost .NET assembly to transpose the iterators proposed in the ruby extension:

1.

As in the FeResPost ruby extension, each iterator method name starts with “each_”, correspondingly, the .NET assembly methods returning an Iterator object have a name that starts with “iter_”. The correspondence between ruby extension methods and .NET assembly methods is obvious: “each_ply” becomes “iter_ply”, “each_material” becomes “iter_material”,...

2.

When the .NET iteration method has no argument, it is a property “getter” that is used instead of a method. Otherwise, a method with argument is defined.

3.

In IronRuby using the .NET assembly, the iteration on the Iterator object is done using “each” iteration method.

Note that to the IronRuby lines given as example above, one prefers the shorter notation: