Remove submodules and split FoundationKit into small parts

[MSch]

Sorry for suggesting this, without participating in the original discussion, but it seems important to me:

As it stands now I can't really use FoundationKit since it pulls in lots and lots of stuff I don't like/can't use (e.g. MagicalRecord)

Why not make foundationkit nimble and split it into multiple repos that can be mixed and matched as people like?

E.g. instead of FoundationKit/Common/NSData+NKCrypto.m just being in the repo with dozens of other things have a dedicated repo 'FoundationKit-Crypto'.

[eaigner]

I don't like third party libs too - therefore I suggested writing the whole thing from scratch. But I'm not the only contributor in this project, so everyone gets some say. But the goal is to make a unified interface (common namespace prefix NK) by subclassing 3rd party classes or via proxy object.

[myell0w]

I don't like the Split-Approach because it would potentially lead to a lot of repos and we would loose the advantage of being able to use everything in foundationkit everywhere else in the repo, e.g MCRelease

My proposal would be to move the submodules (all but cocoalumberjack?) into the (upcoming) app template. Foundationkit would stay more lightweight and the submodules are easier to remove if one doesn't want them. What do you think?

[MSch]

Yeah that makes sense. But I honestly won't use this if it's one big git repo you add to your project.

I much prefer the style with picking what you need, e.g. vendor FoundationKit-Crypto and you get NSData+NKCrypto and no NSView+Whatever

Also all those submodules definitely can go into an example project.

[MSch]

Oops my above comment was an answer to @eaigner.

There can still be a FoundationKit-Common repo.

@myell0w: Is MCRelease this? http://iphonedevelopment.blogspot.com/2010/09/dealloc.html That looks like bullshit, if your class is accessed in a multi threaded env you can't just work around raceconditions like that? Even this is a bug waiting to happen:

_x = x ; x = nil [_x release];

[eaigner]

you could wrap it in a @synchronized (_x) { _x = x ; x = nil [_x release]; }

[MSch]

@eaigner yeah but only if each method in your class doesn't depend on more than one ivar... There's a reason Apple likes GCD + Copying/Immutable data structures

[eaigner]

Well... I'm not using MCRelease so this should be a @myell0w :)

[myell0w]

MCRelease was just an example, there are a lot of things I also want to use when writing stuff for foundationkit, Splitting it up ruins this. Btw a macro like MCRelease makes it much easier to migrate existing code to ARC

[MSch]

@myell0w See #5 on why I think it doesn't make sense to go non-ARC for new projects :)

[MSch]

@myell0w also what about foundationkit-common that gets pulled in by every component?

[MSch]

See http://titanpad.com/foundationkit

Three big projects: FoundationKit + UIKitSquared + AppKitSquared (Names TBD)