Guiding rules for FoundationKit

[MSch]

Here's how I understand FoundationKit (as opposed to PSFoundation)

1. Try to use as little magic as possible and be as clear as possible
2. No premature optimization
3. Be friendly to people that want to copy and paste stuff into their own source

@eaigner added the NK_INLINE macro to NKShorthands.h. (See 4d82e11) I think that runs opposite to these rules.

What does everyone think?

1. Are those rules good or bad?
2. Is NK_INLINE good or bad?

[eaigner]

ad 2. NK_INLINE doesn't really fall under optimization, but rather under consistency with Apple frameworks.

[MSch]

Is NS_INLINE available in our headers? We should use that.

ad 2. I meant your comment about future LLVM version. If that's the reason for NK_INLINE then NK_INLINE is premature optimization

[steipete]

"Be friendly to people that want to copy and paste stuff into their own source"
I like that idea. We shouldn't depend to heavily on meta-language. NK_INLINE is probably something we don't need.
But I'm sure there will be macros that are worth writing, and we have to decide between ultimative modularity or a more efficient (less LOC) framework, i decide for the later. We thus should decide that on a case-on-case basis, and I trust you guys to make that decision.

I just think NK_INLINE is something not really heavily used - but please, correct me if I'm wrong.

On the other hand, Erik introduced me to the great shorthand "_" instead of NSLocalizedString(@"", @"") - and I'm all for using that, even in categories (that may just include NKShorthands.h). If I really wanna use just parts of the framework, I can

a) add the macro file with it (it's just preprocessor stuff, it doesn't hurt or exists globally)
b) add the one line to the .m header
c) use search/replace

Don't forget guys, we're building a better tool for ourselves. Other, imaginary third people should be considered, but our needs come first.