From Blazegraph
Jump to: navigation, search

The name Striterator is intended to convey a merging of Stream and Iterator functionality. It captures an impression I had when I was first exposed to Java at a degree of similarity between an Iterator and an Object stream. Stream-based processing is a very strong idiom and it seems that it should be possible to provide approach Iterators in a similar way.

Furthermore, while Iterators are presented as supporters of in-memory object access, streams are naturally considered to map over files and external connections. This approach appeared arbitrary. For example, if an ObjectInputStream is only used to deliver a stream of Objects, then it is trivial to define an Iterator implementation supplied by it. This acknowledges two things: the similarity of an object stream to an Iterator and the potential for an Iterator to deliver incremental object values.

Stream-based processing is presented as composition, with one stream providing input to another with the output representing some transformation of the input. So the first stage in the development of the Striterators was to replicate that pattern, that a Striterator should consume an input Iterator.

This is demonstrated by the default Striterator implementation, such that:

Iterator striter = new Striterator(iter);

results in the striter simply delegating the Iterator implementation to the source Iterator.

The next stage is to identify some standard transformations to provide direct support for.

  • The Resolver pattern transforms one object into another.
  • The FilterTest pattern filters out invalid objects.
  • The Expander pattern expands each original object into many.
  • The Appender pattern appends another Iterator.
  • The Sorter pattern defines an ordering - requiring eager consumption of the source.
  • The Merger pattern mergers two ordered Iterators.

As is often the case when new approaches are used for solving problems, new possibilities become apparent. Sure it is possible to add transformations to a Striterator and then process the resulting Iterator as a code refactoring exercise, but more interesting is that the resulting Iterator can now be passed as a parameter to or returned from a function, or, if passed as a Striterator may have more transformations applied to it.

Recent BigData enhancements to the Striterator patterns have added the potential for manipulation and remote execution of the Striterator transformation stack.