Put Cocotron on top of MulleObjC

[3a4oT]

Porting Cocotron to mulle-objc should be relatively easy. Remove the Cocotron classes that are supplied by MulleObjC and you might be good to go. Cocotron looks like its also MIT or BSD licensed.

[3a4oT]

@mulle-nat in what way we should address it? I have some thoughts:

1. Make PR to original repo
   OR
2. Clone original project and publish it under BSD3 license (original under MIT) to own mulle-objc repository?

Do you have any other ideas?

[mulle-nat]

I would talk to @cjwl and ask how he would prefer to handle it (Basically if things work out via github notify, I am doing this right now :))

[cjwl]

Hi, if you want to do this it makes sense to make a PR to the original repo which ...

a) makes the required changes to tie Foundation to mulle-objc provided they are MIT and conditionalize them.

b) implement a script which downloads mulle-objc, build it for the desired platforms, and manage the build flags which conditionalize the usage of it in Cocotron

Cocotron supports a variety of optional third party libraries, e.g. openssl for ssl support in CFNetworking stuff, libjpeg for image decompression, etc. Adding mulle-objc would fit into this pattern.

The important thing is that it becomes an optional objc runtime drop-in, Cocotron supports its own runtime, and the gnu ones, mulle would just be another one.

[mulle-nat]

Hi cjwl

thanks for considering to accept a possible future PR for mulle-objc. Very kind.

I don't know if you ever looked at MulleObjC. mulle-objc is not a compatible runtime, there is a list of classes and protocols , that would get #ifdef swapped out from Cocotron/Foundation.

Classes:
    NSAutoreleasePool - garbage collection
    NSCoder - object serialization
    NSObject - the root class of everything
    NSLock - locking for threading
    NSRecursiveLock - recursive locking for threading
    NSInvocation - method call serialization
    NSMethodSignature - method description
    NSProxy - the other root class of everything :=)
    NSThread - threads

Protocols
    NSCoding - object serialization
    NSCopying - object copying
    NSFastEnumeration - support for for ... in loops
    NSObject - for objects that don't want to behave like NSObject but can't be them
    MulleObjCTaggedPointer - enables classes to use tagged pointers
    MulleObjCSingleton - enables classes to produce singletons
    MulleObjCClassCluster - enables classes to act as class clusters

As the compiler declares itself with __MULLE_OBJC__, technically it would be a matter of #if around specific classes:

e.g. Cocotron/Foundation/NSObject.h:

#ifdef __MULLE_OBJC__
#import <MulleObjC/MulleObjC.h>
#else
<previous contents>
#endif

e.g. Cocotron/Foundation/NSObject.m:

#ifndef __MULLE_OBJC__
<previous contents>
#endif

I could see a problem with this, if you were using "bridging" with CoreFoundation classes, but the CoreFoundation in Cocotron seems to be pretty much devoid of actual content, so it's maybe not a problem ?