███ ██ ███ ████ ██, ██████ ███████ ███. ██ █ ███ ███. ████ ███ ███, █ █████ ███. ████ █ ██ █ ███ ███ ██ ██ ██. ██ ███ ██ ███ █ █████. ███ ████ ███ ██, ██ ████ ███ ███ FRA ████. ███ ████ █████ ██, █ ███ ██ ███ █. █████ ███ ██ ██ ███ ███ █ ████ ██ ███. ███ █ ██ ███, █ ███ ██. ██ ███ ████ ███. ███ ██████ ███ ██, ██ ███ █ ███ ██.

████ █████ ███ ███. ██ █ █, ███ █ ██ ███ █, ███ █ ██. ████ ██████ ██ █ ███ ███ ███████. ███ █ ██ ██ ██ ████ ███ █ █ ██. ████ ██████, ██ █████ ███ ████, █ ██ ████ ██, █ ██████ ██ ███ █ ██. ██ ████ █████ ██ █ █████. ███ ███ ██ █ ██, ██████ █████ █. ███ ██ ████ ██. ██ ████ ███ ███. ████ █ ████ ██. █ ███ ████ ███, █ ██ ██████ █ ███ ████. ███ █ ██ ██ ██ ███ ████ █ ██ ███. ███ ████ ██ ███ ███ ████ ████. ██ ██ ██ █ ███ ████ ███.

███ █ ███ █. ████ ██ ███ █ ███ ███ ███ █ █ ██. ██ ████ █████ ████. ██ ███ ██ ██ ██ ████ ██ █████ ███ ███. ███ ██ ██, ███ █ ██ █, █████ ██ ███. ██ ███ ██ ████ ███ ████ █ ███ ██ █████. ██ █ ██ █ ██ ███ ████. ███ ██ ██████ ██, █ ████ ███ ███ ██. █████ ████, ██ █ ████ ████, ███ ██ █████ ██, █ █████ ███ ███ █ ██. ███ ██ ██, ███ ████ ████ █, ███ ██ ███. █ █ █████ ███. ████ ████ █████ ███ ██ ████. █████ ██ ███ ███ █ ████ ██ ███ █ ███ ████ ███ ███; █████ █████, ██ ██ ████ █████, ███ ██ █████ █ FRA █ ██ ████ ███ ██ ██ ███. ██ █ ██ ██. ██ █ ████ ███. ██ ██ █, █████ █ █████ █ ██, ████ ██ ███. ██ ███. ███ █ ██ ███, █ ████ ██.

█████ █ ██ ██ ██ ███ █████. ██ ████ ███████ ███ █ ████. ███ ███ ██ █ ██ █████ ██ ████ ██ ████. ██████ ████ ███ ██ ██ ██. ██ █ █████ ██. ██ █████ ████ ███. ███ ████ █████ ██, █ ████ ███ ███ █. ██ █████ ████ ██ ██ █████. ██ ██████, █ █ █████ ███, ██ ██ █████ ██, ██ ████ ███ █ █ ██ █. ██ ██ ██, ████ ██ ███ █ ██, █████ █ ███. ██ ████, ██ █ ██████ ███, █ ██ ████ ███, █████ ███ ███ ██ █████ ██. ██ █ ███ █ ██ ███ ████. ██ ███ ███, ████ █ FRA ███ ██, █████ █ ██. ███ ████ ████ ██ █ ████. ████ ██ ███ ██, ██ ████ ██. ██████ ████ ███ ██ ██ ████. ██ █████ ███ ████.

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)

(Well, roughly. It actually looks like this, but I couldn’t find a decent-resolution Swedish one.)

This was a sensible design for the right-handed majority when it was introduced, some time in the stone age. However, since then, something quite important has happened: the keyboard has been joined by another input device, which I suspect is used more than the keypad by most people who are not cursed with an Excel-dominated career.

The ergonomics of the extended keyboard + mouse combination is quite, quite horrible. The human arm is not optimized for sitting turned out 30 degrees for hours at a time.

Apple has tried at least twice to solve this in one obvious way: remove all or part of the junk on the right. This has been widely, or at least loudly, decried, leading to the Extended ADB Keyboard for high-end Macs in the deep past and to extended keyboards for all in the USB era. There is another solution, though:

Unfortunately, day-to-day conservatism means that people, in the aggregate, will loudly complain about having to adopt a superior solution if it involves half an hour of retraining. I’m sure many would point out that this is why we still have rectangular QWERTY keyboards in the first place. Still, if anyone can force change down our throats and make us like it, it’s Apple.

I urge all EU citizens to contact an MEP, via e-mail or (preferably) phone, and encourage them to support the Citizens’ Rights Amendments, which reaffirm net neutrality and anti-censorship positions adopted by the European Parliament in the first reading but subsequently removed by the Council of Ministers in their “common position”.

The primary purpose of these amendments is to make it explicit that the European Convention on Human Rights applies to internet and telecoms legislation. This should be obvious, but it is clear from the actions of politicians that it is not; it is all too clear that many see the internet as a frivolous toy, and civil rights obviously do not apply to toys. (It occurs to me that politicians are probably among those in the western world least affected by the digital communications revolution; if they need to communicate, they talk to their secretaries.)

Draft texts of the amendments (not yet numbered) can be found here: part I, part II, part III. There’s a (rather bad) campaign site here, and a less bad editorial – for all that it’s in a pointy-haired e-mag – in Computer World UK here.

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.

This is not about programming. It’s about something that actually matters.

There’s been a little media coverage recently about a Swedish law that’s been in the works for a while. (The Register, Slashdot on The Register, The Local Edit: and IDG/PCWorld, European Digital Rights, Ars Technica; new portal site in Swedish). The law will permit the National Defense Radio Establishment (FRA, Försvarets radioanstalt) to carry out surveillance over the air and in cables crossing the Swedish border.

Surveillance over the air has been carried out since the 1940s, and satellite surveillance since 1976. This has been unconstitutional since 1995, when the European Convention on Human Rights was adopted as part of the Swedish constitution. The former second-in-command of FRA, Anders Wik, admitted this in a tape recording made public last saturday. This has received almost no attention in the Swedish press. Creating a law that permits the activity will make it legal under the EHCR¹.

The law was originally drafted by the Social Democratic Party, but withdrawn because it “received an unfortunate amount of attention”. It was reintroduced by the current four-party alliance in late 2006 (with a quick consultation carried out in the week between Christmas and New Year), but was suspended for one year by a rare minority veto instigated by the Social Democrats, who suddenly felt it should be adjusted to provide more checks and balances.

Defenders of the new law point out that it specifies that “military intelligence activity” [försvarsunderrättelseverksamhet] may only target “foreign matters” [utrikes förhållanden]. That restriction is actually already in place. However, it is the stated legal opinion of FRA that when they work for non-military authorities, such as the police, the customs office or the tax board, this is not “military intelligence activity” and is therefore not restricted to “foreign matters”. Besides that, determining that, for instance, an e-mail message is to or from a Swede involves analyzing it; as pointed out by the Council on Legislation, personal integrity is violated by opening the envelope, not just by copying the contents.

The obvious problem with this type of legislation is that it can easily be abused, especially when it’s written in very broad terms. However, there is another problem: even if it never is abused, the very existence of surveillance is oppressive and changes people’s patterns of communication.

A recent survey from Germany shows that a large portion of the population has changed or under certain circumstances would change their behaviour due to Germany’s implementation of the data retention directive. This “only” involves storing information about the participants in communication and their location. A law that allows essentially arbitrary civil authorities to order searches of the contents of people’s communication can be reasonably expected to affect behaviour more extensively. As such, citizens’ freedom of expression is curtailed. Without a functioning freedom of expression, democracy means nothing.

The proposed law is not a technical adjustment of foreign intelligence activity, as its defenders wish us to believe. It is a direct assault on democracy itself. It is expected to pass with a seven-vote majority eleven days from now, unless we can once again raise an “unfortunate amount of attention.”

Footnote: I know that we’re already being spied on by foreign agencies, but that’s less important. Foreign governments are not in a position to oppress us, except by taking over the government of Sweden. This is reflected by the Swedish bill of rights, which in several cases protects² the citizen “in his relations with the public institutions” [gentemot det allmänna].

¹ If you accept that it is “necessary in a democratic society in the interests of national security, public safety or the economic well-being of the country, for the prevention of disorder or crime, for the protection of health or morals, or for the protection of the rights and freedoms of others.”
² Sort of. Except for the EHCR, the Swedish constitution is not enforceable.