On 17 Jan 2007, at 00:55, Quentin Mathé wrote:
I have been thinking about having such foreach macro recently but
haven't done anything yet.
My reasons in favor of foreach would be:
- it is badly easy to forget setting or resetting initially to nil
the variable used to store the current iterator value
- it is boring to copy/paste this boilerplate code over and over
- it is painfull to refactor a method that contains more than one
iteration
This following blog entry <http://mjtsai.com/blog/2006/07/15/cocoa-
foreach-macro/> discuss some interesting improvements like imp
caching and optional type checking.
This is the set of macros I use:
#define FOREACHI(collection,object) FOREACH(collection,object,id)
#define FOREACH(collection,object,type) FOREACHE
(collection,object,type,object ## enumerator)
#define FOREACHE(collection,object,type,enumerator)\
NSEnumerator * enumerator = [collection objectEnumerator];\
type object;\
IMP next ## object ## in ## enumerator = \
[enumerator methodForSelector:@selector(nextObject)];\
while(enumerator != nil && (object = next ## object ## in ##
enumerator(\
enumerator,\
@selector(nextObject))))
For dictionnaries or arrays, I was considering using JSON or a
simple plist string to set up a new collection.
Something like [NSDictionary dictionaryWithString: @"{ key =
value; ... }"] and a shorcut could be [NSDictionary dict: @"{ key =
value; ... }"]
But in the end a macro is probably better since it defers less
checks to runtime. It's surely even shorter too.
The macros Nicolas had were (as I recall):
#define AS ,
#define D(...) [NSDictionary dictionaryWithObjectsAndKeys:items
__VA_ARGS__, nil]
You would then use it like this:
NSDictionary * example = D(foo AS @"foo, bar AS @"bar");
This lets you use dictionaries as a quick substitute for creating
simple classes that just encapsulate some data. It could be really
nice in combination with a dedicated NSZone as described in my other
post so that they can very cheaply be created and destroyed.
My initial idea might be still interesting with something like
[NSPropertyListSerialization propertyListWithString: "a complex
plist string"] that would return an object tree made of array and/
or dictionary. Renaming [NSPropertyListSerialization
propertyListWithString: "a complex plist string"] to [ETCollection
collectionWithPListString:] may feel more intuitive. ETCollection
would be some kind of generic collection abstraction.
Yes, it's a shame the NS* collections don't share a common superclass
Otherwise I think it could be quite nice to duplicate some NSString
methods but with shorter names. For example [NSString concat:
@"bla"] would be identical to [NSString stringByAppendingString:
@"bla"]
Isn't stringByAppendingString an instance method? It's a shame the C
preprocessor isn't very expressive, because this would be a really
nice thing to do with the preprocessor if you could just define a
CONCAT macro with a variable number of arguments that would
concatenate all of the strings. It could be done as a function, but
that would be expensive since inline functions aren't allowed to be
recursive...
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
