4 posts • joined Wednesday 6th September 2006 07:27 GMT
Just a quick clarification: a java.util.Enumeration, as shown in the NeXT example, is an example of the Iterator pattern not the Enumeration Method pattern. Yes, the name is confusing.
One of the defining characteristics of Enumeration Method is that the user of a collection does not write the loop: the collection encapsulates the loop mechanism. The Enumeration Method itself calls back to code provided by the caller.
In terms of callbacks, yes, in C it is possible to do this, as the article pointed out -- "it is not a pattern that is restricted to Smalltalk: it can be applied in C, using function pointers". However, the downside is that without closures, generics, an object-based type system or other suitable mechanisms you can end up with void * all over the place.
As time goes on it does indeed appear that Java is acquiring more powerful features, but it appears to be at the expense of consistent language design and invariably makes parts of the language more complex. Whether the additional complexity is worth it in all cases is questionable. For many recent and forthcoming features, it might be that Java is simply the wrong base language to extend, i.e. "I wouldn't start from here" :->
In terms of Ruby's iteration, the most obvious influences are Smalltalk, with blocks of code treated as objects, and CLU, with a coroutine-like ability to suspend execution of a block and yield a value (an approach that has since been incorporated into C#).
In Scheme, Enumeration Method is actually most like the for-each function, but as I was focusing on a more strictly functional programming perspective the map function was closer. The fold (or apply or reduce) family of functions found in languages such as Lisp, Scheme, Haskell, etc, is actually not a particularly representative example of an Enumeration Method since, for a single list, each application of the passed function receives two arguments rather than one: one is a list element and the other is the result of the previous application of the function on the previous element (and so on). Definitely useful, but not as direct or simple an example of a straight Enumeration Method.
A Couple of Responses
The idea of using Internal Iterator (aka Enumeration Method) was mentioned in the article. However, in claiming that "there are essentially only three general designs that keep the collection's internal representation hidden from the caller" one of the important constraints governing the choice of technique was that "the caller needs to be able to know the position of elements in some way". Effective a pattern as Enumeration Method is, this particular constraint excludes it from the running. Change the design criteria, such as requiring exclusive locked access to a collection over a loop, and the selection changes, in this case to include Enumeration Method and exclude Iterator.
The topic of encapsulated iteration, and the trade-offs between these patterns, are interesting enough in their own right to justify another article (see http://www.regdeveloper.co.uk/2006/09/04/to_iterate_human/).
In terms of creating a kind of dual representation within a collection to support more time efficient indexing, yes this can be a consideration if indexing is a strong requirement. However, if is not, it will always be a more expensive and complex approach. As noted, it will always be more costly in terms of space and maintaining a side-by-side representation will increase code complexity and, slightly, the cost of other operations that modify the collection, because they must now keep the index structure in synch as well.
- World's OLDEST human DNA found in leg bone – but that's not the only boning going on...
- Lightning strikes USB bosses: Next-gen jacks will be REVERSIBLE
- Pics Brit inventors' GRAVITY POWERED LIGHT ships out after just 1 year
- Beijing leans on Microsoft to maintain Windows XP support
- Storagebod Oh no, RBS has gone titsup again... but is it JUST BAD LUCK?