waffle

LINQ (Language Integrated Query) is a new feature of the forthcoming .NET framework revision (post-Vista!) and C# 3.0 that’ll let you use an SQL-like query language imposed by the language, framework and compiler to do, basically, queries on any data structure. (Channel 9 has a video on LINQ and it is definitely worthwhile. DLinq, the database abstraction layer, also happens to implement ActiveRecord. Very impressive.)

What do we need to add to Obj-C or to Cocoa to make this happen? LINQ works by importing the namespace System.Query, which adds methods to every object implementing the IEnumerable<T> interface (enumerable and returns a specific type). We can do that.

We can’t directly add categories to everything implementing an Obj-C protocol (there’s no NSEnumeratorProviding), but we can add a category on NSObject, and do some inquisitive poking and prodding in the vein of [self respondsToSelector:@selector(linqObjectEnumerator)], and add categories for the Foundation collections that fall through to the correct enumerator methods (most commonly - objectEnumerator). Based on calling this and seeing if it returns anything, we could selectively implement methods for the clauses.

We also have a way of specifying predicates (NSPredicate) and drilling down data structures (key-value paths). However, this is about how far you can go. What’s left? For one thing, the integration of the query into the language. Another is a more human and flexible way of specifying NSPredicates - like any other comparison in Obj-C, basically. If you watch that video again, you’ll see the huge disconnect between filtering an array and offering what LINQ offers.

What’s interesting about LINQ is that half of it is based on C# (or ultimately MSIL) catching-up to Obj-C in things like adding methods to existing classes or inventing stuff only needed by being strongly-early-typed (a result is actually an anonymous type with properties having inferred names, each predicate comparison is a lambda expression, and the whole deal drops tens of new keywords into C#). The other half is the .NET side of things driving off in the distance, leaving the Cocoa lover in me drooling at my keyboard. Cocoa, and its data access in specific, could grow enormously by stealing the right things from LINQ and I’m hoping that this is on Apple’s radar (hint, hint) if not in Leopard then at least in time for 10.6.

The new, more specific, Wikipedia warnings. “This article is about a shitty local band no one has ever heard of. Please stop adding entries about your shitty local band.”

Raw 1080p video takes up a shitload of room. Now, there’s also audio to be added to that. And I used to think HDMI’s 10.2Gbps was hyperbole and overkill.

It’s the talk of the town again. The rumors of an Apple-produced phone - an “iPhone”, as it were - have been circulating for years. The basic gist, the strength of the argument is that there’s no really good music phone. According to mostly everyone, Apple can more or less work out a phone, stick choice pieces of an iPod into it and it’ll go flying off the shelves. A done deal, right?

If that’s the way they’re going to go about it, they’ll certainly sell a few phones. But come on. They’ve already done that with the ROKR phone. Didn’t turn out great. The simple truth is that there’s more to making a genuinely good phone than making it work in just one area.

No, what I see Apple making - if they’re making one - is a phone that is easy to navigate and whose programs doesn’t suck. No phone that I’ve for years has had a thoroughly nice suite of basic functions - messaging, reasonable web browsing, address book, calculator, alarm, call history and calendar. There are bright spots and really dark spots on most models. I have a Sony Ericsson model that can nail a note to the standby menu screen, and the Nokia I used to have slapped the Sony Ericsson around the block when it came to the address book.

It’s important to know that I don’t live on my phone, but that it’s just not that hard to find bugs in phone software. That’s the sad state of it. No amount of “well, but can you call people with it?” crack-making will wish away the need that people have - created or not - to use the programs, so every phone has them, but they’re just not good.

Apple has the experience with desktop applications, the experience with creating usable handheld interfaces and the experience with these kinds of applications specifically (including integration and syncing and making a whole bundle) to pull this off if they want to. If they want real mainstream appeal and parlay, of course they’re going to stick music playing into it, but the road to real success with a cell phone is one that’s really good.