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. I've built other engines in C and C++, but each time doing so involved writing 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 none really provided the generic programming or object library I wanted.

So I wrote my own.

Were the 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 code needs to be easy to understand and maintain. It also must must be suitable for platforms with (relatively) limited resources. 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.

Wish List

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 probing, 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 text manipulation, 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.

The dynamic selector cache currently uses a naive round-robin approach for assigning cache lines to selectors. It should really gather cache miss statistics and adjust cache lines over time. Implementing this needs to wait until there are some better real-world test cases lest the attempt actually degrade performance.