Obsolete as of Leopard and Objective-C 2.0, this macro by Allan Odgaard:

#ifndef forall
#define forall(collection, element) \
  for( \
    id _enumerator = [collection objectEnumerator], \
    element; \
    element = [_enumerator nextObject];)
#endif

lets you quickly enumerate any Cocoa collection that responds to -objectEnumerator with a simple forall(collection, element) { … } statement.

Nowadays you should be using Objective-C 2.0’s fast enumeration instead.

(…everything looks like a nail.)

Hammer is a context-free parser generator framework written in ObjC (with ports in mind to Ruby and, c/o Joe Osborn, Erlang).

It’s currently runtime-only, although you can certainly archive the parsers it makes and load them, but the intent is to compile them using llvm.

It doesn’t use a lexer, and it’s surprisingly featureful. Lazy rules are coming, as is n-token lookahead, just as soon as I sort out the model in my head and get time to write it!

More thorough description coming soon, email me if you want to know more now.

Locus is a language built and designed to interoperate with Objective-C. Its native types are Objective-C types; at its very lightest, it serves as a definition syntax for NSArray, NSDictionary, and NSString instances.

This article assumes familiarity with Objective-C, and, to some degree, the Foundation framework in Cocoa. Locus can be used in isolation, but it shines best with Objective-C.

Literals

Locus’ syntax is designed to be simple and clear, and as such it borrows a lot from JavaScript, especially JSON. Arrays, dictionaries, and strings are taken outright from it:

[1, 2, 3]
{ one: 1, two: 2 }
"stringy!"

Dictionary literals also provide the basis of Locus’ object-orientation; as in JavaScript, dictionaries double as objects, and methods assigned to slots in the dictionary can be called via messages.

Methods

To that end, methods are defined with a vaguely Ruby-ish syntax:

method = { x: 1, y |
   x * y
}

Here x has a default value, 1, but y is unspecified. You would call it like this:

method(y: 2)
method(x: 2, y: 3)
method(2, 3) # same as x: 2, y: 3
method(2) # same as y: 2

Objects

As discussed, putting methods into dictionaries gives you object-orientation. You could do that like this:

Rectangle = {
   width: 1,
   height: 1,
   area = {
      width * height
   }
}

As well as giving an example of argument-less methods, this also shows encapsulation—these methods have access to slots bound in their context, in this case width and height.

After Rectangle has been defined, if you wanted to add a perimeter calculation to it, you could do so easily like so:

Rectangle perimeter = {
   2 * width + 2 * height
}

Locus respects the order of operations.

Messages

Dictionary/object access is done by chaining symbols together separated by spaces. So if you had a Rectangle instance named rect you would get its perimeter like so:

rect perimeter()

If a method takes a single argument, you can call that method with a literal (not a variable) argument omitting the parentheses that would normally wrap its argument list. This is done for pure prettiness; compare the following two equivalent method calls:

foo([1, 2, 3])
foo [1, 2, 3]

The leading space in the second example can be omitted, which can make methods seem like they’re taking a subscript operator (as in C). This allows the syntax to represent both methods taking e.g. arrays and methods that take an index into their objects with the same syntax. Compare:

sum [1, 2, 3]
matrix at[1, 2]

The same syntax is used, with the same meaning to the language, but the latter looks a lot like indexes in C. This flexibility also applies to other literals:

[1, "two"] collect { each |
   each description()
}
print "I am a banana!"
sin 3.1415

Unlike in Ruby, however, if there are multiple arguments, the parentheses are required.

Expressions

Expressions can be separated either by newlines (and other optional whitespace) or by semicolons or both:

1
2

is equivalent to:

1 ; 2

As you may have noticed before, methods do not use an explicit return statement; instead, the value of a set of expressions in a block is the value of the last expression.

Further, expressions can be extended across multiple lines by using the \ character at the end of the line, as in C macros and bash scripts, making these equivalent:

NSAutoreleasePool alloc \
   init
NSAutoreleasePool alloc init

RXObjectBinder

(Kiss some glue code goodbye!)

Ever since I started using bindings, and especially since their momentum has kept growing, I've wanted something like an NSObjectController turned backwards. How so?

NSObjectController instances let you bind to their target object's properties. For example, if you have an instance of a custom class, controls can bind to an NSObjectController instance representing it, and thus display (and control) specifics of its state without writing glue code.

What if your custom class is a view class, though? What if you have a view in a collection view that you want to make represent the individual items that the collection view is displaying? You can't bind your view's properties as-is, because it isn't instantiated by Interface Builder (and thus its -exposedBindings method won't be called). What do you do?

You either

• manually bind the view to the collection view item in your window controller (or some other responsible controller class), presumably adding outlets and a few lines to your -awakeFromNib implementation, or
• hack up an IB3 plugin to instantiate your view and its bindings

I want this sort of thing all the time. It drives me nuts that NSObjectController won't let me do it. So I wrote RXObjectBinder, which will. Here's how it works:

1. Instantiate RXObjectBinder (it's the red hypercube seen up top)
2. Connect its representedObject outlet to the appropriate object (probably most frequently a view)
3. On its Attributes inspector, add the keys that you'd like to bind.
4. On its Bindings inspector, bind them.

You'll obviously also have to either link against RXObjectBinderFramework (annoying) or just compile the RXObjectBinder class in (not as annoying). I'd recommend the latter.

At runtime, the bindings are forwarded directly to the representedObject, so there shouldn't be any bizarre proxying screw-ups here (10.4-era NSTreeController, anyone?). In practice I'm finding this to be very pleasant, and not nearly as much of an unholy hack as I feared it would be. It's entirely documented-API, blessed-methods-of-InterfaceBuilderKit—kosher, in fact—and quite minimalistic.

In short, I like it, and I hope you will too. Download away, or if you have git feel free to get the source directly:

git clone git://github.com/robrix/objectbinder.git

Feel free to submit patches to me.

It's BSD licensed, natch, and your nibs should deploy just fine to both 10.4 and 10.5. (Only 10.5 has been tested so far.) If you want to edit your RXObjectBinder-bearing nibs under 10.4/IB2 then I can't help you—perhaps no one can.

I love find almost as much as I love DTerm (full disclosure: I work for Decimus Software), but, being a Mac user, sometimes I want to handle my files with the Finder, too.

Unfortunately, combining the shell with the Finder requires AppleScript, which is really painful when all you want to do is select some files. However, with rb-appscript things are somewhat better—we can trade the painful AppleScript for some (slightly ugly, if you ask me, but RubyOSA wasn’t working for me) Ruby.

As an example of its use, the command:

find . -name '*.jpg'

will return the paths of all the jpgs in the working directory (and recursively, in fact). Selecting them in the Finder would be useful if we wanted to email them to someone, so wouldn’t it be nice to just write something like:

find . -name '*.jpg' |
   select_in_finder

and drag them over to Mail?

That was the idea behind this script.

#!/usr/bin/env ruby -rubygems 
require "appscript"
Appscript::app('Finder').
   selection.
   set(STDIN.
      readlines.
      collect do |line|
         MacTypes::FileURL.
         path(line.strip).to_alias
      end)

It doesn't do any error checking, and you should bear in mind that the Finder will simply ignore any files that aren't in its displayed folder when in column mode; in list mode it is able to select divergent paths correctly.

But when all’s said and done, it's pretty sweet to be able to, say, select all the unknown screenshots in the current folder's git repository:

git status |
   grep modified |
   awk '{print $3}' |
   select_in_finder

Download select_in_finder, put it somewhere in your $PATH, and enjoy. Don't forget to email me your comments, suggestions, and adulation!