I don’t think my random musings have much influence on the design of the language, but if I don’t write it down nobody’s going to know how nuts I am, so here’s a semi-concrete proposal for contextual types and generics for Objective-C. Since anyone even mentioning generics in the vicinity of Objective-C will inevitably be flamed for trying to turn it into C++, this is followed by an aside entitled Why This is Not the Baby-eating Spawn of Bjarne Stroustrup. (Nothing personal, Bjarne.)

Types in Objective-C

A fundamental characteristic of Objective-C is that it has two separate type systems: the dynamic type system, which applies to objects, and the static type system, which applies to variables (which may or may not refer to objects).

As far as objects are concerned, the static type system is optional — you can refer to any object with the type id, except when calling a method whose type may be ambiguous. The static type system is also advisory — it suggests to programmers, the compiler and other tools such as the IDE and analyzer what the class of an object may be at runtime, but doesn’t constrain the object. A variable of type NSString * may actually refer to an NSArray at runtime, and method calls will dynamically go to NSArray’s implementation.

My proposal deals only with the static type system. The idea is to provide information that helps the compiler and analyzer check your logic, and the IDE to provide better suggestions. This is done by replacing id with more specific static types in most of the situations it’s used in. The generated code is not affected in any way. The proposal does not introduce bondage and discipline on the language; the new types can always be cast away.

Contextual Types

By far the most common use of id is as the return type for methods that may return an instance of “this” class, or of the subclass it’s called on. The obvious examples are +alloc and -init.

The IDE and, I believe, the analyzer already use heuristics to determine the return type of +alloc and -init, but I propose formalizing this in code. It would look something like this:

@interface NSObject <NSObject>
{
    Class   isa;
}

+ (void)load;

+ (void) initialize;
- ([:Self]) init;

+ ([:Self]) new;
+ ([:Self]) allocWithZone:(NSZone *)zone;
+ ([:Self]) alloc;

// ...

+ ([:Superclass]) superclass;
+ ([:Class]) class;
- ([:Superclass]) superclass;
- ([:Class]) class;

@end

When calling a class method, [:Class] resolves to the receiver (or, type-equivalently, a pointer to an instance the receiver’s metaclass), and [:Self] resolves to a pointer to an instance of the receiver. [:Superclass] resolves to the superclass of the receiver. For instances, they resolve as for class methods on the class of the instance.

I’m sure some people will object to the conceptual purity of this design, and possibly the names and syntax. The colon is a bit odd — it’s there to avoid ambiguity with generics (see below). All of these are minor quibbles; the syntax would need to be reviewed if actually implementing it.

So what’s the point? Consider the following code:

NSString *s = [[NSArray alloc] init];

As it stands, this is perfectly valid and doesn’t generate a compiler diagnostic. With the addition of contextual types it would, because:

• The type of +[NSArray alloc] (inherited from NSObject) is [:Self], which resolves to NSArray *.
• The receiver of the -init is thus known to be an NSArray.
• The type of -[NSArray init] (inherited from NSObject) is [:Self], which again resolves to NSArray *.
• Therefore, the right hand side of the assignment is of type NSArray *, and the assignment is invalid.

If, for some reason, you really wanted to do that, you could use an explicit cast to get rid of the diagnostic.

Generics

The other major use of id is for polymorphic collections. True polymorphic collections are great! But some of the time, you only want to put one kind of object in your collection, and would appreciate the computer doing the drudge work of checking that you didn’t put the wrong stuff in the wrong place.

From the perspective of the previous section, generics are a simple extension to contextual types. Instead of restricting you to [:Self] and the highly specialized [:Class] and [:Superclass], you can provide one or more class names as a parameter to a type declaration. Example time again:

@interface MyThingHolder[ThingType = id] : NSObject
{
    [ThingType]     thing;
}

- ([:Self]) initWithThing:([ThingType])thing;

- (void) setThing:([ThingType])thing;
- ([ThingType]) thing;

// Or, for modernists:
@property (readonly, nonatomic) [ThingType] thing;

@end

// ...
MyThingHolder[NSString] *holder = [[MyThingHolder[NSString] alloc] initWithThing:@"foo"];
holder.thing = [NSNumber numberWithBool:MAYBE];      // Warning: type mismatch
holder.thing = (id)[NSNumber numberWithBool:MAYBE];  // OK. (an issue here would be inconsistent with general Objective-C behaviour.)

// Or, equivalently:
typedef MyThingHolder[NSString] MyStringHolder;
MyStringHolder *holder = [[MyStringHolder alloc] initWithThing:@"foo"];

Some notes: the type parameter can only be a class, since specialized code is not generated for each type. (See Why This is Not the Baby-eating Spawn of Bjarne Stroustrup below.) Since the type parameter is always a class, I have made the * implicit. This is cleaner, but could well lead to confusion and is quite likely a bad idea. (If only I had a time machine…)

The type parameter has a default value, previously unheard of in Objective-C, so that you can ignore generics and create a “vanilla” MyThingHolder that works just like in traditional Objective-C. This provides an upgrade path for existing classes:

@interface NSArray[Item <NSObject> = id <NSObject>] : NSObject <NSCopying, NSMutableCopying, NSCoding, NSFastEnumeration>

- (NSUInteger) count;
- ([Item]) objectAtIndex:(NSUInteger)index;

@end

@interface NSArray[Item] (NSExtendedArray)

- (NSArray[Item] *) arrayByAddingObject:([Item])anObject;
- (NSArray[Item] *) arrayByAddingObjectsFromArray:(NSArray[Item] *)otherArray;
// ...
- (BOOL)containsObject:([Item])anObject;
// ...
+ ([:Self[Item]]) arrayWithObject:([Item])anObject;
// ...


@interface NSDictionary[Key <NSCopying, NSObject> = id <NSCopying, NSObject>, Value <NSObject> = id <NSObject>] : NSObject <NSCopying, NSMutableCopying, NSCoding, NSFastEnumeration>

- (NSUInteger) count;
- ([Value]) objectForKey:([Key])aKey;
- (NSEnumerator[Key] *)keyEnumerator;

@end

@interface NSDictionary[Key, Value] (NSExtendedDictionary)

- (NSArray[Key] *) allKeys;
- (NSArray[Key] *) allKeysForObject:([Value])anObject;
- (NSArray[Value] *) allValues;
// ...
- (BOOL) isEqualToDictionary:(NSDictionary[Key, Value] *)otherDictionary;
- (NSEnumerator[Value] *) objectEnumerator;
- (NSArray[Value] *) objectsForKeys:(NSArray[Key] *)keys notFoundMarker:([Value])marker;
// ...
- (void) getObjects:([Value] *)objects andKeys:([Key] *)keys;
// ...

These examples introduce an additional concept: restrictions on type parameters, in this case protocol requirements. The other obvious type of restriction would be a superclass requirement, such as [Type: NSString = NSString].

Using these genericized versions in the same manner as the existing versions would require no code changes – as long as you’re using them with objects that fulfil the protocol requirements, which already exist but aren’t explicit in code.

Type Conformance

A fundamental question for static type systems with inheritance is when implicit casts are allowed. There are subtleties here, some of which I probably haven’t considered, and I have a feeling I’ve considered some and then forgotten about them. The most obvious case is when the base type and each type parameter could be validly cast:

NSMutableArray[NSMutableString] *a = whatever;
NSMutableArray *b = a;            // OK, b is NSMutableArray[id <NSObject>]
NSMutableArray[NSString] *c = a;  // OK
a = b;                            // Not OK, implicit cast from NSMutableArray[NSString] to NSMutableArray[NSMutableString]
NSArray[NSMutableString] *d = a;  // OK
NSArray[NSString] *e = a;         // OK
id f = a;                         // OK

As indicated above, passing an id when a parameter type is expected is necessary for consistency with Objective-C in general:

NSMutableArray[NSString] *a = whatever;
[a addObject:[NSNumber numberWithInt:42]];      // Type mismatch, assuming +numberWithInt: is declared to return [:Self]
[a addObject:(id)[NSNumber numberWithInt:42]];  // OK

How about the case where a method returns an unadorned type?

@interface LegacyThing: NSObject
- (NSArray *) legacyListOfStrings;
@end

LegacyThing *l = whatever;
NSArray[NSString] *list = [l legacyListOfStrings];

In order to minimize the burden of adopting generic syntax, I’d suggest explicitly permitting this, with an optional warning. (The non-generic equivalent, assigning an id <NSObject> to an NSString *, generates the somewhat unexpected warning “type ‘id <NSObject>’ does not conform to the ‘NSCopying’ protocol” in GCC and nothing in Clang. Assigning an NSObject * to an NSString * generates warnings in both. My proposal is that assigning a T to a T[P] should work without warning by default, even if the default type parameter is a class rather than id with or without protocols.)

Why This is Not the Baby-eating Spawn of Bjarne Stroustrup

Many Objective-C programmers are refugees from the blasted wasteland of C++, and will reflexively cringe at the similarity with templates:

std::vector<Duck> ducks;
Chicken chicken;
ducks.push_back(chicken);             // Error
ducks.push_back(*(Duck *)chicken);    // Horrible crash here or some time in the future, maybe.

NSArray[Duck] *ducks = [NSArray new];
Chicken *chicken = [Chicken new];
[ducks addObject:chicken];            // Warning: type mismatch
[ducks addObject:(Duck *)chicken];    // No problem, unless you call -quack on it.

While the difference should hopefully be clear by now, I’ll spell it out: in C++, std::vector<Duck> creates an entirely new class (with bits of Duck inlined into it). The Objective-C-with-generics version only provides hints to the compiler, so it can catch mistakes. It doesn’t stop you from putting chickens among your ducks, or make the duck array reject chickens at runtime, or generate a new array-of-chickens class.

In earlier discussions of generics, it has been stated that this type of mistake is rare in practice and should be caught with unit tests. If you feel that way, you’re welcome to stick to your current approach, and the introduction of generics, as described, will not affect you.

To avoid ballooning side effects of generics, I’ve deliberately avoided suggesting generic functions and methods (i.e., ones whose return type is dependent on one or more argument types, independent of their class in the case of methods).

One Last Thing

An effect of the above is that I want the language to contain types like NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] *. That doesn’t mean I want to spend my time typing NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] *, even with autocomplete. Fortunately, there exists a well-known solution to this problem: type inference.

If I access a member of an array of the aforementioned sesquipedalian type, I get an NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]] *. What’s more, the compiler knows this. The benefit of static typing lies primarily in checking what I do with my dictionary, rather than checking that the item I retrieved is what I thought it was, so I should be able to ask it to type a variable appropriately.

I quite like C++1x’s solution of recycling the auto keyword for this use, but that would conflict with Objective-C’s goal of being a strict superset of C. There are various other choices, such as var or any — or maybe ego. In any case, type inference would lead to code like:

typedef NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] MyHorribleNestedType;  // TODO: replace with sensible model classes.

MyHorribleNestedType *array = whatever;
var element = [array objectAtIndex:0];              // Type is inferred as NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]*
var subEntry = [NSArray arrayWithObject:@"bloop"];  // Type is inferred as NSArray[NSString]
[element setObject:subEntry forKey:@"moop"];        // Type mismatch: expected NSSet[NSMutableArray[NSNumber]], got NSArray[NSString]

A subtlety here: the return type of [NSArray arrayWithObject:@"bloop"] (declared previously) is [:Self[Item]], which is inferred from the receiver (the NSArray class object) and argument to resolve to NSArray[NSString]. Instead of typedefing MyHorribleNestedType, we could have constructed the type implicitly in the same way. like everything else in the proposal, this is optional; if you used id or explicit, unparameterized types in this example, the type mismatch would not be detected, but the generated code would be identical.

Summary

• The id type is very powerful and flexible. However, most of the time you don’t need this flexibility, and type checking is helpful — this is why Objective-C has optional static type checking in the first place, and almost all Objective-C code opts in to it.
• The proposal would not impose any new restrictions, or any new guarantees. It would only extend (optional) static type checking to cases which are currently not covered.
• It would not involve any implicit code generation, and no runtime overhead.
• Combined with type inference, it could catch errors without additional code.
• There would be no new collections, and no implementation changes to existing ones other than updated type declarations. (Updated headers would work with the existing implementations.)
• If you really don’t want static type checking, you can continue using id everywhere.
• I mean it about the “optional”. The proposed change would have no effect unless adopted both by a class and its clients. A parameterized collection pointer can be cast to plain one at any time with no cost.

JAMultiTypeSavePanelController is a class (abstracted from ImageIO Export for Acorn) to handle the case where you want to offer the user a choice of formats to save in.

It wraps an NSSavePanel and handles all the UTI and extension details. You can provide a customised NSSavePanel or let the controller create one. The only restriction is that the controller appropriates the accessory view. Usage is similar to NSSavePanel itself:

NSArray *types =
    [NSArray arrayWithObjects:@"com.apple.rtfd", @"public.rtf", @"public.plain-text", nil];
JAMultiTypeSavePanelController *controller =
    [JAMultiTypeSavePanelController controllerWithSupportedUTIs:types];
controller.autoSaveSelectedUTIKey = @"document format"; // Optional: preferences key for selected type.
controller.sortTypesByName = NO; // Optional: show in specified order instead of alphabetically by display name.
[controller beginSheetForDirectory:nil
                              file:@"untitled 42"
                    modalForWindow:docWindow
                     modalDelegate:self
                    didEndSelector:@selector(savePanelDidEnd:returnCode:contextInfo:)
                       contextInfo:nil];

-runModalForDirectory:file: is also supported.

Code (MIT/X11 license)

As an early Christmas present to fellow lovers of twisted, evil code that should never have seen the light of day under any circumstances whatsoever, I hereby present an implementation of the first half of that wish.

Caveat lector

Now, when I say it’s evil, I really, really mean it. We’re talking about building objects in the data section of your code by packing structs, thus depending on data layout (and as such, depending on the old 32-bit runtime). We’re talking about nested macros with lots of ?:s in them. We’re talking about gcc’s built-in parser pseudo-functions. Hearken to the words of Greg Parker, official Objective-C Runtime Wrangler at Apple:

@gparker: @ahruman JANumberLiteral would break in several exciting ways in 64-bit. Might almost be safe enough in 32-bit, though.
@ahruman: @gparker Yeah, I know. I’ll be pasting “If you do this in real life, I’ll have to track you down and shoot you” warnings all over it. :-)
@gparker: @ahruman Don't shoot 'em, just maim 'em a bit. I want my turn after you're done.
@ahruman: @gparker That’s what kneecaps were invented for.

Be told.

Overview

So, all that aside… what we’re looking at here is a macro $N(n) which takes a number and returns an NSNumber. (The convention of using dollar signs for macros implementing desired language features was introduced by the other Jens A.) If passed a compile-time constant, it will produce a constant object, i.e. a single, immortal instance based in the data section with no instantiation overhead, just like a string object constant. If passed a non-constant, it will give you a normal autoreleased NSNumber instead.

Constant NSStrings work by creating a struct with the following layout: { &__CFConstantStringClassReference, 1992, "foo", 3 }, where 1992 is a flag field and 3 is the length of the string. (Note that this is not the NSConstantString from the bottom of NSString.h. I believe this change was made in the OS X 10.2 SDK.) __CFConstantStringClassReference is a symbol exported from CoreFoundation.framework and implicitly declared in all Objective-C or Objective-C++ files by the compiler.¹ My task, once I chose to accept it, was to do something similar for NSNumber.

Trying to build actual NSCFNumbers would be an unnecessary extra evil. Instead, I subclassed the abstract NSNumber twice, once for long longs and once for doubles, giving me a known layout to target. The subclasses also override -retain, -release and -autorelease to do nothing, in the manner of a singleton. Then, building an instance is conceptually simple:

const static struct { Class isa; double value; } fakeObj =
{ [JAFloatNumber class], 42.0 };
NSNumber *number = (NSNumber *)&fakeObj;

The structure needs to be declared static so that it doesn’t evaporate at the end of the containing scope. This presents a dilemma, however: static initializers must be constant expressions, and a method call doesn’t qualify. Besides, we want the object to be constant data.

Luckily for us, classes are represented by global symbols like any other. Well, almost like any other. Unlike symbols based on C identifiers, their linker symbols don’t start with an underscore but with a dot, meaning you can’t reference them the usual way. Fortunately, gcc provides us with a solution in the form of asm labels:

extern const struct objc_class JAFloatLiteralClassObject
        __asm__(".objc_class_name_JAFloatNumber");

The basic implementation then becomes:

#define JANUMBERLITERAL_CONSTANT_FLOAT(n) \
        ({ static const struct { const struct objc_class *isa; double value; } \
        object = { &JAFloatLiteralClassObject, (n) }; \
        (NSNumber *)&object; })

A problem here is that, despite all those consts, a non-const value can be used in Objective-C++. (In plain Objective-C, you get a moderately helpful warning about non-const initializers.) If you write a function that returns JANUMBERLITERAL_CONSTANT_FLOAT(random());, each instance will return the same object but its value will change, which is rather bad. The fix is to wrap this up in a macro that uses __builtin_constant_p() to ensure constant objects are only created with constant values. For non-constant values, normal autoreleased NSNumbers are created instead.

Results

The above pieces, along with a bunch of extra preprocessor stuff to handle the distinctions between Objective-C and Objective-C++ and between integer and floating point values gives us a $N(n) macro which works as advertised: if given an integer constant it returns a JAIntegerNumber, for a floating point constant it returns a JAFloatNumber, and for a non-constant it returns an autoreleased NSCFNumber. But is it really working as intended? The following code:

static NSNumber *GetNumber(void)
{
    return $N(42.0);
}

disassembles to:

    .const_data
    .align 2
_object.67163:
    .long   .objc_class_name_JAFloatNumber  // isa
    .long   0           // low bytes of 42.0
    .long   1078263808  // high bytes of 42.0

…with the actual use of the object inlined (in an optimized build) to movl $_object.67163, (%esp). The values 0 and 1078263808 correspond to the little-endian hex value of 42.0: 00000000 00004540. In other words, this really is an object as constant data. For comparison, the NSString literal used in the sample code disassembles to:

    .cstring
LC0:
    .ascii "Hello, World! %@ = %li (%@)\0"
    .section __DATA, __cfstring
    .align 2
LC1:
    .long   ___CFConstantStringClassReference // isa
    .long   1992  // flags
    .long   LC0   // bytes pointer
    .long   27    // length

Conclusion

So there you have it: fully-functional, constant NSNumber objects, as long as you don’t use the 64-bit runtime. Now don’t go actually using it, or I’ll have to shoot your kneecaps off and leave you to Greg.

Oh yeah, the code is on Google Code. For a much simpler macro that just gives you an NSNumber, automatically choosing between integer and floating-point representations, try natevw’s.

^{^1} Its value, on my system, is 0xa00034a0. Traditionally (pre Leopard), a value above 0xFFF would mean it’s a real Objective-C class rather than a CF type tag, but that test is no longer in the CFLite source in Leopard, so it may have changed.

If you declare extern const Class __CFConstantStringClassReference; in an Objective-C++ file, you’ll get the error “'__CFConstantStringClassReference' has a previous declaration as 'int __CFConstantStringClassReference []'”. In Objective-C, you won’t be told a type, just that it was “previously declared here”, referring to the location “<built-in>:0”.

Easy Dictionary

This allows you to use arbitrary accessors on dictionaries, or arbitrary properties if you declare them first (no definition necessary). Example:

@interface NSDictionary (MyProperties)
@property (retain) NSString *fruit;
@end
...
NSMutableDictionary *myDict = [NSMutableDictionary dictionary];
dict.fruit = @"apple";  // -setFruit: method is generated dynamically.

Google Code, original lisppaste

Silly String

This defines a new string concatenation operator, :. Well, almost. It allows you to append any number of strings (or arbitrary object descriptions) to a string using the following syntax:

[@"string " : @"other string " : arbitraryObject : @" yet another string "]

Unfortunately, a header is required in this case to avoid unknown selector warnings.
Google Code, original lisppaste

Disclaimer

As noted in each of the files, I don’t recommend actually using these. They’re exercises in understanding the mechanics of the language rather than actually useful utilities. In particular, if you use Easy Dictionary you’re in for a world of hurt when you try to use a property that NSDictionary already has, like count, or description, or release.

Specifically, the projects in question are:

• GLSL Bindings Sample
• ImageIO Export plug-in for Acorn.
• JAPriorityQueue
• JAPropertyListAccessors
• KeyFromQWERTY
• KeyNaming
• S3TCDecompression
• SCDialControl
• SCSliderWithTextField

For information about the various code bits and bobs, see here.

I fully expect that the next person who tries to grab some of my code will find it to onerous to dig through the subversion repo. To that person, my message is: tough.

Now personally, I like to specify my defaults in plists, and if I was hard-coding them I’d use an enum. However, I thought of a mildly amusing implementation, so I wrote it (MIT/X11 license). It turned out to be less interestingly ugly than I expected, but did give me an opportunity to play with __builtin_constant_p(). This means that (if you’re using gcc) KEY_FROM_QWERTY_BODY(ex), where ex is a constant expression, will itself be a constant expression, and if ex is otherwise known at compile time to be constant (e.g. a locally-defined const int, which is not a constant expression in C) it will be constant-folded; in other cases, a function call will be generated.

Also included is code to generate the header, specifically the big ?:-based expression that does the work, using whatever keyboard layout happens to be active. Note, however, that the current implementation only includes keys that generate a single ASCII character, and skips dead keys. It includes capital letters as aliases for their lowercase equivalents, but not other shifted keys.

Conveniently, I’ve also written a library to get a display string for a virtual key code. That one does use the user’s current keyboard layout.

Why would you want to do that? Ahh, well, that part is covered by the iPhone SDK NDA. Lawyers, eh? It must be a pretty good reason, though, given testimonials like this.

Executive summary for people who don’t like rambling anecdotes: property lists and user defaults should always be type-checked, and this makes it easy.

Oolite is highly moddable, with over 150 expansion packs. Most of them are interoperable, and typically many will be in use at once. Essentially all of these contain property lists, generally written by hand by non-programmers, often on systems without plutil or Property List Editor. As such, many contain parse errors or structural problems.

Previous versions of Oolite blithely ignored the imperfections of mere humans. Unparseable property lists were effectively ignored, leading to unexpected behaviour, often quite subtle. Structural errors, however, caused exceptions, most of them seemingly at random.

The current test releases address the syntax issues by dumping the error string from NSPropertyListSerialization and the path to the relevant file to the game’s run log. A certain amount of context-sensitive type checking is done in certain areas, such as scripting (yes, property lists are used for scripting, although that’ll be deprecated in the next stable release).

The most significant fix, however, has been to replace most uses of -objectForKey: and -objectAtIndex: with methods that check types and perform conversions where they make sense. In particular, strings are automatically converted to numbers and booleans where appropriate, which is needed to work with the more pleasant OpenStep plist syntax. When a plist value can’t be converted to the required type, or simply isn’t there, an appropriate default value is used. The game will no longer try to get keyed objects from an array, or find the first character of a dictionary. Instead of code like this:

// Hope plist has correct structure.
unsigned myMagicNumber = [[[plist objectForKey:@"someArray"] objectAtIndex:3] unsignedIntValue];

or more fault-tolerant code like this:

unsigned myMagicNumber = 0;
id array = [plist objectForKey:@"someArray"];
if ([array isKindOfClass:[NSArray class]] && [array count] > 3)
{
    id number = [array objectAtIndex:3];
    if ([number respondsToSelector:@selector(unsignedIntValue)])
    {
        myMagicNumber = [number unsignedIntValue];
    }
}

we now have code like this:

unsigned myMagicNumber = [[plist arrayForKey:@"someArray"] unsignedIntAtIndex:3];

which will not throw an exception if @"someArray" is not an array or if the array has less than four members, but will instead return 0. It’s also shorter than the broken version. Default values other than 0 can be provided in the form [array integerAtIndex:3 defaultValue:-1] or [dictionary unsignedShortForKey:@"value" defaultValue:14].

Oolite is obviously an extreme case, but many applications deal with property lists. Even more deal with NSUserDefaults, which of course is a wrapper around property lists. You may think that you know what you’re putting into user defaults and can therefore rely on it to be correctly structured, but if you’re thinking that you’re wrong. First, users will modify your preferences file, break it, and forget they did it. Second, your code is buggy. If you write any sort of collection to your prefs, there’s a chance that you’ll put an object of the wrong class there if the phase of the moon is unusual. If you don’t check it when you read it, this will cause an exception, and you’ll end up guiding a user through digging around in ~/Library to clean up your mess. Better to be fault-tolerant to start with.

So, here it is: JAPropertyListAccessors 1.0.2 (MIT/X11 license). It provides:

• A non-throwing variant of -[NSArray objectAtIndex:].
• Functions to convert objects (NSNumber or NSString) to all standard integer types, as well as float and double, clamping the results rather than overflowing, and returning a user-specified default value if no conversion can be performed.
• Convenience methods for accessing integers, floats, strings, arrays, dictionaries, sets, or objects of a specified class from NSArray, NSDictionary or NSUserDefaults. The following transparent conversions are performed when appropriate: NSString to numbers; NSNumber and NSDate to NSString; NSArray to NSSet.
• Convenience methods to set integers and floating-point values in NSMutableArray, NSMutableDictionary and NSUserDefaults.
• Unit tests for the primitive conversion functions.
• Compatible with 32-bit and 64-bit runtimes, and with garbage-collected and non-GC code.
• Very little in the way of comments.

Update (version 1.0.1): Default value (rather than nil) is now returned when conversion to string fails. String conversion now uses -stringValue if available.

]]> http://jens.ayton.se/blag/property-list-extractors/feed/ 1 http://jens.ayton.se/blag/hackin-ur-crash-reportz/ http://jens.ayton.se/blag/hackin-ur-crash-reportz/#comments Tue, 18 Mar 2008 02:47:49 +0000 Jens Ayton http://jens.ayton.se/blag/hackin-ur-crash-reportz/ Continue reading →]]> In a conversation on #macdev, it was pointed out that the Crash Reporter has an “Application Specific Information:” line when certain Apple apps crash. This obviously warranted investigation, and through the powers of Google it was determined that said investigation had in fact happened a few months ago. How fortunate that we didn’t spend time investigating it and writing test cases, only to find someone had already done a better job.

Anyway, this is an entirely unsupported thing to do, and the means of doing it may disappear at any time, so don’t. But if you do, do it cleanly, like this:

#ifndef NDEBUG
/*  Function to set “Application Specific Information” field in crash reporter
    log in Leopard. Extremely unsupported, so not used in release builds.
*/
static void InitCrashReporterInfo(void);
static void SetCrashReporterInfo(const char *info);
static BOOL sCrashReporterInfoAvailable = NO;
#else
#define InitCrashReporterInfo() do {} while (0)
#define SetCrashReporterInfo(i) do {} while (0)
#define sCrashReporterInfoAvailable 0
#endif

/* Insert code here. Or make it non-static, depending on what you’re doing. */

#ifndef NDEBUG
static char **sCrashReporterInfo = NULL;
static char *sOldCrashReporterInfo = NULL;
static NSLock *sCrashReporterInfoLock = nil;

static void InitCrashReporterInfo(void)
{
    // Load secret symbol __crashreporter_info__; don’t do anything if not found.
    sCrashReporterInfo = dlsym(RTLD_DEFAULT, "__crashreporter_info__");
    if (sCrashReporterInfo != NULL)
    {
        // We'll need a lock, too.
        sCrashReporterInfoLock = [[NSLock alloc] init];
        if (sCrashReporterInfoLock != nil)
        {
            sCrashReporterInfoAvailable = YES;
        }
        else
        {
            sCrashReporterInfo = NULL;
        }
    }
}

static void SetCrashReporterInfo(const char *info)
{
    char                    *copy = NULL, *old = NULL;

    /*  Don’t do anything if setup failed or the string is NULL or empty.
        (The NULL and empty checks may not be desirable in other uses.)
    */
    if (!sCrashReporterInfoAvailable || info == NULL || *info == '\0')  return;

    // Copy the string, which we assume to be dynamic...
    copy = strdup(info);
    if (copy == NULL)  return;

    /*  ...and swap it in.
        Note that we keep a separate pointer to the old value, in case
        something else overwrites __crashreporter_info__.
    */
    [sCrashReporterInfoLock lock];
    *sCrashReporterInfo = copy;
    old = sOldCrashReporterInfo;
    sOldCrashReporterInfo = copy;
    [sCrashReporterInfoLock unlock];

    // Delete our old string.
    if (old != NULL)  free(old);
}
#endif

For this to be actually useful, you’d want to be using Smart Crash Reports (apparently coming soonish to a Leopardy computer near you) or something similar.

]]> http://jens.ayton.se/blag/hackin-ur-crash-reportz/feed/ 2 http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/ http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/#comments Fri, 09 Nov 2007 18:51:42 +0000 Jens Ayton http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/ Continue reading →]]> Note: As of Snow Leopard, this functionality has been superseded by an official Dock tile plug-in mechanism.

---

One of the minor yet shiny new features of Mac OS X 10.5 is that iCal’s dock icon now shows the correct date even when iCal is not running. Some assumed this to be hard-coded functionality in the dock, but a few brave souls – well, one, being me – decided to find out.The following lines in iCal’s Info.plist are a bit of a hint:

<key>DockExtra</key>
<string>iCalDockExtra.bundle</string>

iCalDockExtra.bundle can be found in iCal’s Resources directory. 90 seconds with class-dump, otool, and class-dump again show that the bundle implements a subclass of DockExtra, which in turn is defined in the private SystemUIPlugin.framework.

Having retrieved the interface declaration for the DockExtra class from class-dump, it is a simple matter to implement a subclass which logs which methods are called and when. As it turns out, the only ones called are -_initWithController: and -dealloc, but through the power of my mighty brain I worked out that I could draw the dock icon whenever I wished, using -getContext: to get a drawing context and size, -setDockImageFromContext to update the image in the dock and -releaseContext to clean up afterwards.

And that’s pretty much it. Code is here. Read the Read Me first. (The most important caveat is that the bundle is never unloaded while SystemUIServer is running.) If someone actually uses this for something useful, please tell me about it.

Edit: I thought I’d said this earlier, but apparently not: as pointed out in the comments, Alacatia Labs published the same information a week before me, and did a slightly better job too. If I had used the power of the intergoogles, I would have known that, but then I’d have missed the fun of working it out.

]]> http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/feed/ 23