NSArray enumerator orders- interface or implementation detail? also: removing conditional statements
NSArray enumerator orders- interface or implementation detail? also: removing conditional statements
- Subject: NSArray enumerator orders- interface or implementation detail? also: removing conditional statements
- From: Joe Osborn <email@hidden>
- Date: Mon, 7 Oct 2002 14:21:40 -0500
In short-- can I rely upon -[NSArray objectEnumerator] to return an
enumerator which will enumerate through the array's elements in the
order of their indices in the array? Can I sort the array by some
arbitrary criterion and then get an enumerator that is likewise sorted?
I know that the answers to these questions are yes- but... is the fact
that their answer is such an integral part of the interface? Or is it
merely an implementation detail that could differ between
implementations/versions of NSArray?
I believe that other collections return enumerators with objects in
undefined order. It's obvious I can't rely on those to be in any
particular order, because they're not ordered collections.
So: For ordered collections, is it customary(required?) to always
return via objectEnumerator an enumerator whose objects are ordered as
the ordered collection's were?
--joie
ps: Furthermore, what is the general consensus on which of these two
bits of code is preferable?
1:
//index is defined earlier
SEL possibleActions[] = {@selector(doSomething),
@selector(doSomethingElse)};
[self performSelector:possibleActions[index]];
2:
if(index == 0)
{
[self doSomething];
}
else if(index == 1)
{
[self doSomethingElse];
}
//or likewise
switch(index)
{
case 0:
[self doSomething];
break;
case 1:
[self doSomethingElse];
break;
default:
}
I would say that the former is preferable, not only because it uses
fewer lines of code to express the same idea, but it's also a lot
easier to add new actions. It could be construed as harder-to-read,
however. I'm not sure.
I'm certain that all those if...else ifs and that switch... statement
are not quite good for object-oriented thing. refactorings such as
Replace Conditional With Polymorphism come to mind, but aren't really
applicable in this case. (Switches are just glorified gotos after all,
aren't they?)
Thanks for your ideas.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.