3 ms·
Doing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to
by jedsmith 16y ago
Doing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to context switch to a header just to mentally resolve symbols.
Instead of using a macro for the selector:
NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil];
It would probably be far more efficient to macro the entire call using C99's variadics:
NSDictionary *frob = DICT(v1, k1, v0, k0);
Still wouldn't walk that road, personally.
- leon_ 16y agoYup, macros are a bad idea in that regard. Had to work on a codebase where the prior programmer had fancy defs like _dict k1, v1, k2, v2, k3, v3 dict_ I wasn't too happy about that :/
- deleted 16y ago[deleted]
- Groxx 16y agoThe reason I went for the selector is because it makes the macro into essentially a function-typedef. I don't know any languages which allow typedefs to specify things like `Class.short = Class.super_long_name_here`, even though it's essentially the same concept, especially if looked at from a C standpoint. It's a minimally-intelligent text replacement. IMO, something like `[NSDictionary with:key,val,key,val,nil]` is far less brain-taxing than `DICT(key,val,key,val)`. It fits without modifying the language or the syntax, it merely makes something long shorter, and the usage implies it does nothing "shiny" - you even keep the class name you're calling, making it clearer what you should be expecting, and it still allows access to all other parameters without modification or even thinking differently. DICT(...) is ambiguous about what kind of dictionary it's returning.