﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on Design patterns in the test of time: Iterator</title><description>Frisian,
Next / MoveNext does NOT do two things.
It tries to move to the next one, returning true if it succeeded.
The return value is if the next operation was successful, not if the future next operation will be.
And Parallel.ForEach works _using_ an iterator. </description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment8</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment8</guid><pubDate>Mon, 28 Jan 2013 13:36:55 GMT</pubDate></item><item><title>Frisian commented on Design patterns in the test of time: Iterator</title><description>I am not a C# programmer, but what I could take from an example for Parallel.ForEach (http://msdn.microsoft.com/en-us/library/dd460720.aspx) seems to prove my point: it's a method with a callback, that is presented one element at a time.
And that is definitely not the GoF-Iterator, for which you provided the Wikipedia link in your article.
Interestingly, both "standard" implementations (IEnumerator in C#, Iterator in Java) share a common problem: they are mixing command and query. Iterator.next() not only returns the current element, but also advances to the next one. IEnumerator.MoveNext() moves to the next element and tells, if there is a next element at all.
Likewise, they both don't adhere to "Tell, don't ask", thus promoting coupling.
Lastly, I wasn't complaining about the abstraction level being "low", but being "too low". The loop really doesn't belong on the caller's side.
</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment7</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment7</guid><pubDate>Mon, 28 Jan 2013 13:24:57 GMT</pubDate></item><item><title>Ayende Rahien commented on Design patterns in the test of time: Iterator</title><description>Frisian,
Where on earth did you get the idea that iterator forbid parallel execution.
See Parallel.For and Parallel.ForEach as good counter examples.
Sure, iterator is low level, but most design patterns are.</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment6</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment6</guid><pubDate>Mon, 28 Jan 2013 11:03:08 GMT</pubDate></item><item><title>Frisian commented on Design patterns in the test of time: Iterator</title><description>The Iterator pattern may be omnipresent, but IMHO that doesn't say anything about its current value:
- The abstraction level of the pattern is too low: In order to work, the pattern forces you to place a loop into your code. It's a code smell in my book, if someone else's code dictates the control structures in my code. Iterating over a collection can be abstracted away in a forEach() method, that takes a callback handler, which in turn is invoked for every element of the collection. Every SAX parser works like this.
- Because of the low abstraction level the Iterator pattern effectively prohibits parallel execution of a piece of code. Nowadays, that is almost bad in itself. With a dedicated forEach() method on the other hand, that's rather simple: Mark the callback handler as side-effect-free by flag, annotation or marker interface and the iteration can be parallelized. By comparison, every SQL statement is written in a way that allows the database to execute it in parallel.
- An iterator is stateful and mutable. Passing around an iterator as an argument leads to complex coupling of the affected code. Refactoring such code will be arduous at best.
</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment5</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment5</guid><pubDate>Mon, 28 Jan 2013 10:04:47 GMT</pubDate></item><item><title>Ayende Rahien commented on Design patterns in the test of time: Iterator</title><description>Sergey,
Sure, do you have any specific questions?</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment4</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment4</guid><pubDate>Mon, 21 Jan 2013 08:15:37 GMT</pubDate></item><item><title>kindof commented on Design patterns in the test of time: Iterator</title><description>Ayende, did you know that Scott Hanselman and Rob Conery make jokes of your voice at the end of Hanselminutes 353? :D</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment3</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment3</guid><pubDate>Sun, 20 Jan 2013 13:59:41 GMT</pubDate></item><item><title>Sergey Shumov commented on Design patterns in the test of time: Iterator</title><description>Ayende, what do you think about to write a couple of posts on how things are organized in Hibernating Rhinos? 
It would be interesting to read about your CI process, development workflow, internal rules, priorities management, etc...</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment2</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment2</guid><pubDate>Fri, 18 Jan 2013 14:30:04 GMT</pubDate></item><item><title>Ryan Heath commented on Design patterns in the test of time: Iterator</title><description>Ah, remembering those days when I first met them, C++ STL anyone? ;)

// Ryan</description><link>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment1</link><guid>http://ayende.com/160706/design-patterns-in-the-test-of-time-iterator#comment1</guid><pubDate>Fri, 18 Jan 2013 12:26:20 GMT</pubDate></item></channel></rss>