Comments on: Cocoa foreach Macro

By: Michael

Michael — Sun, 18 Mar 2007 02:22:28 +0000

Here's an interesting alternative. Personally, I think it's too verbose, though.

By: Michael

Michael — Sun, 16 Jul 2006 21:09:59 +0000

Yes, I used "## object" in my original macro for the same reason. I just don't see any reason to prefer the "## object" to using loop-scope variables. In any case, both work, so I'll stop discussing this. It think the casts are perfectly safe, but I agree with Matt that they're a bit unsightly. Though so are the for-loops in their own way, but that's why we have a macro to hide it all. :-)

By: Wincent Colaiuta

Wincent Colaiuta — Sun, 16 Jul 2006 18:31:06 +0000

Ugh, that nested for loops solution looks pretty ghastly. What's wrong with the original casts? In all cases the types involved are pointers (id, IMP etc) so there is no danger in casting them.

By: Wincent Colaiuta

Wincent Colaiuta — Sun, 16 Jul 2006 18:28:18 +0000

If you were really worried about collisions of two "_i" variables (really "_object") then you could switch to using "## collection" instead; I can't think of any reason why you'd have nested enumerators iterating over the same collection. The reason why I chose "object" to introduce some uniqueness into the names is that in my usage patterns when using nested enumerators I find that I'm always using two different types of object and so the variable names will naturally be different; things like "title" and "author", or "inner" and "outer" and so forth.

By: Michael

Michael — Sat, 15 Jul 2006 19:36:23 +0000

Well, the truth is that I use the debugger only rarely. I prefer logging. Anyway, I think your version with ## will have the same problem in the debugger. You'll also have two i's, as well as two of each of the helper _i variables. The main difference is that if you use i for one loop and j for the other, your helper variables will have unique names in the debugger and mine won't. That doesn't bother me because I'll probably be ignoring the helper variables, anyway, and because it's probably bad style to use nested loops both with i. The main reason I like the loop-scoping (and the ## in the old version of my macro) is that it prevents collisions of the helper variable names when two foreach loops are in sequence or nested.

By: Wincent Colaiuta

Wincent Colaiuta — Sat, 15 Jul 2006 19:17:19 +0000

Yes, it will compile and run, but I think it's bad practice to rely on the behaviour in general. What do you do if you're in the debugger looking at nested enumerations?

for (int i = 0; i < 5; i++)
{
for (int i = 0; i < 5; i++)
{
// what do I do here if I want to print the value of the outer "i"?
}
}

By: Michael

Michael — Sat, 15 Jul 2006 17:38:33 +0000

I haven't seen any problems with namespace clashes. Nesting a foreach creates a new scope for its variables.

By: Wincent Colaiuta

Wincent Colaiuta — Sat, 15 Jul 2006 17:16:53 +0000

When I saw your original article I wrote some macros of my own, documented here:

http://wincent.com/a/knowledge-base/archives/2006/01/objectivec_enum.php

It's a good improvement that you've used loop-local variables. I did that too. But if you want to be able to nest enumerations you'll find that you still get namespace clashes. One way to solve this is with the concatenation operator (##). To illustrate (don't know if this will be readable or the code will get eaten but going to paste it in anyway):

#define WO_ENUMERATE(collection, object) \
for (id WOMacroEnumerator_ ## object = [collection objectEnumerator], \
WOMacroSelector_ ## object = (id)@selector(nextObject), \
WOMacroMethod_ ## object = (id)[WOMacroEnumerator_ ## object methodForSelector:(SEL)WOMacroSelector_ ## object], \
object = WOMacroEnumerator_ ## object ? \
((IMP)WOMacroMethod_ ## object)(WOMacroEnumerator_ ## object, (SEL)WOMacroSelector_ ## object) : nil; \
object != nil; \
object = ((IMP)WOMacroMethod_ ## object)(WOMacroEnumerator_ ## object, (SEL)WOMacroSelector_ ## object))

/*! Perl-like syntax for WO_ENUMERATE. */
#define foreach(object, collection) WO_ENUMERATE(collection, object)