Project Goals and Roadmap

Why does this even exist?

The Duck Object Library started when I considered porting my game engine from MacOS/iOS to Android, Linux and game consoles. Now I've built other engines in C and C++, but each time involved building a lot of boilerplate code to handle reference counting, message passing, unicode strings and whatnot--all stuff provided by Objective-C out-of-the-box. I considered some other object systems, but most were proprietary or GPL, and nothing really provided the generic programming or object library I wanted.

So I wrote my own.

Were Objective-C runtime and Apple's Foundation libraries widely available on most platforms, it's safe to say this library probably wouldn't exist.

Development Goals

1. Small. The object runtime and library must be suitable for platforms with relatively tight resource constraints. The idea is something like libc, not Boost.
2. Portable. The code needs to be in plain C with minimal dependencies. Porting to a new platform should take a weekend, not a month.
3. Fast-ish. Performance is important--up to a point. Readability and portability take precedence. Performance-critical code can always be written in plain C.

Ideas For Future Development

Networking and HTTP utilities would be nice, but an argument could be made that you should really use system provided ones for security. Something like NSURL would be a good first step.

A proper time/date class, or formatting functions that work with DKNumber. Heck, improved (or any) locale support would be good.

A string syntax for predicates similar to NSPredicate. The main question is whether to use a prefix notation (easy implementation) or infix notation (more readable).

Improved hash table performance. The current implementation uses quadratic hashing, which is reasonably fast, but wastes memory (load must be < 0.5), and is only about half the speed of NSDictionary.

More unicode support. DKString currently supports enough UTF-8 for basic string functions, but more powerful string comparison and locale support would be nice. The main question is how much of the ICU package to include before it makes sense to just link against the whole library.

Regular expression support is certainly a nice-to-have. It'd likely be implemented as DKString wrappers around the ICU regex library.