Le 18 janv. 07 à 15:03, David Chisnall a écrit :
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))))
Looks good. Yet I would prefer FOREACH(object, collection) and FOREACH
(object, type, collection) or for the last one FOREACH(type, object,
collection).
Mostly because it's a bit closer to usual objc 'while ((object =
[enumerator nextObject]) != nil)' and also closer to foreach in other
languages like Java, C# and Objc 2.
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.
True, but I'm unsure to really like the use of 'AS', specially
because it's optional and I wouldn't use it personally I think. I
would type D(foo, @"foo", bar, @"bar").
It could be more readable to reverse the order of objects and keys
and also to use DICT rather than just D.
DICT(@"foo" <- foo,
@"bar" <- bar)
I like <- better than AS but it's probably not a wise choice since
it's enough distinct from C syntax and doesn't stand as a macro.
D(@"foo" AS foo,
@"bar" AS bar)
The reversal of object and key order makes it more similar to class
declaration.
We could eventually introduces A(foo, bar) to create an autoreleased
array.
I think it would be more useful to return mutable collections than
immutable as D currently does.
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
We can probably change the superclass of collection classes without
any issues at runtime :-)
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?
yes. My code wasn't clear about that sorry.
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...
Why not create a -concat: method which takes a variable number of
arguments, this would do the trick well. Then we could have a CONCAT
macro mapped to it.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
