Home

Quick Start

Building the library
Initializing the Runtime
Reference Counting

Runtime

Classes & Objects
Interfaces
Message Handlers Properties
Reflection

Libary

Data Types

DKData | DKString

DKBoolean | DKNumber | DKPair | DKStruct

Containers

Interfaces
DKCollection | DKList | DKDictionary | DKSet

Types
DKArray | DKLinkedList | DKHashTable | DKBinaryTree | DKGraph

Common Interfaces

DKAllocation | DKCopying

DKComparison | DKConversion | DKDescription | DKLocking

DKBuffer | DKStream

Thread Synchronization

DKThread | DKThreadPool

DKMutex | DKCondition | DKReadWriteLock

File I/O

DKFile - File Streams
DKEgg - Binary Serialization
DKJSON - JSON Serialization
DKShell - Multipart data
DKXML - XML Parsing

Everything Else

DKEnum - Mapping Strings to Integars
DKPredicate - Logical Predicates

DKPlatform - System Utilities
DKConfig - Build Configuration
DKEncoding - Binary Type Info
DKUnicode - Unicode Support Functions

Low-Level Storage Types
DKByteArray | DKGenericArray | DKGenericHashTable | DKNodePool

Project Goals & Road Map

1. Additions to the library should keep the core library size in mind. The idea is something like libc, not Boost.
2. Modifications to the library should consider not breaking compatibility, yet prefer fixing inconsistent and unintuitive patterns and always remove anything that is patently unsafe.
3. Performance is important--up to a point. Readability and portability take precedence.

Some possible areas 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.