4

I understand what the stop parameter is for, but I'm curious about why this is a BOOL * instead of just a BOOL. Is it because the value itself needs to exist outside of block scope, so that enumerateObjectsUsingBlock: has access to the value potentially assigned to it by the block itself?

Community
  • 1
  • 1
ybakos
  • 8,152
  • 7
  • 46
  • 74

1 Answers1

4

To answer your question (though it looks like a dupe) the block needs to tell its caller to stop enumerating if it's found what it's looking for. There are two choices in C:

  • return YES to continue or return NO to stop.
  • Set a variable in the caller's scope, hence the BOOL *.

Apple chose the second approach, although I think the first approach is both simpler (one less parameter) and more intuitive.

It cannot be just BOOL as that only sets the local copy of the variable, not the variable in the caller's scope.

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
  • The one difference that using the second technique _could_ make is that the Block has access to the previous iteration's decision about stopping. Of course, it's (unfortunately?) not documented to work this way -- there's no guarantee that the `stop` value is the same from step to step. – jscs May 12 '13 at 19:15
  • 1
    @JoshCaswell But presumably it must always be `NO` otherwise the block would not be entered again? – trojanfoe May 12 '13 at 19:54
  • bbum made a comment on my answer to the other question about concurrent enumeration and the stop flag being "advisory"; that's the case I'm thinking of. It's not entirely clear whether it's _always_ possible for enumeration to continue, or only if concurrency is requested. In those cases, it might be handy to be able to signal "I already figured out that I'm done", although of course you could have a local `__block` variable if that's necessary. – jscs May 12 '13 at 20:10
  • @JoshCaswell Yeah, it seems the "contract" of this block is not well defined; there seems to be a lot of second-guessing going on. – trojanfoe May 12 '13 at 22:50