I’ve put out PB 0.8. It has a small number of preference and hotkey fixes, upgrades to the latest ShortcutRecorder (which took a lot more work than I hoped, and I still think may be a little flakey), dropped 10.4 support (because of the latest ShortcutRecorder), and adds experimental Rowmote support. (I may accidentally list “rowmote” as “rowmate” in the changelog; sorry about that.) I say “experimental” because I haven’t gotten around to testing it myself. The author of Rowmote kindly provided me a patch, and I’ve applied it and nothing seems to have blown up.
I’m planning at least another day of PB work this week, so vote on the Issues list for things you most care about and I’ll hit those first. Testing 10.6 support is obviously top of the charts. My main production box is still 10.5, and that’s where I run PB, so I haven’t actually run into the problem yet. But I have 10.6 boxes around to test with.
I know there are a lot of significant bumps with PB these days. I focus almost all of my development time on my full time Mac and iPhone projects, and only look at PB now and then (since it does everything I really want it to). But later this week I’ll make some more time to take care of the bigger issues that impact folks the most. Pandora is still my favorite music service, and I spend a lot of time listening to it. I like to help others enjoy it as much as I do.
The long-lasting power of Snow Leopard from The Yankee Group.
Ever since I first saw GCD at WWDC, I’ve been amazed by it and eager to give it a real spin. But since the vast majority of my work is in low-level libraries that run on both Mac and iPhone, GCD is closed to me (as is garbage collection; more on that later). I’ve said that multi-core would come to mobile devices because everything will come to mobile devices (laptops are the new desktops, and mobile is the new laptop). And for the iPhone, multi-core also makes a lot of sense by allowing Apple to dedicate a core to its own use during important functions like phone calls. But Carl Howe makes an even more compelling argument for mobile multi-core: better battery life.
With multi-core comes another strong possibility: garbage collection. The availability of a second core makes this more likely on iPhone. Yes, memory is tighter, but ever-growing. And GC will likely do a better job of reclaiming memory faster than much of the leaky programs I see from novice programmers. But to do it well, I think a second core is a real must. I’ve grown good at memory management over the years, and it’s hard for me to write GC Cocoa because it “feels wrong.” But I think I could get used to it…. And it would help alleviate the biggest class of coding error I see in Cocoa programs.
Of course, the clang static analyzer will probably help get rid of 90% of those errors anyway, so maybe the need for GC just went way down…. Have I mentioned recently how incredible clang really is? I desperately long for them to finish bringing it to Obj-C++ so I can use it.
NSCopying is not always as simple to implement as you would think. Apple has a good write-up discussing the complexities, but let me elaborate. Forgive some ranting digressions. It’s important to know how to work around the problems I’m going to discuss, but it’s also important to understand how insane it is to have to work around this issue.
First, there’s the fairly obvious problem of deep versus shallow copies. If object foo has an instance variable *bar, should a copy of foo have a second pointer to bar, or should it have its own copy of whatever bar points to? There is no way to answer this question generally; it depends on the nature of the objects.
Most of the time, this can be dealt with fairly easily by implementing the accessors with the correct behavior (retain versus copy), and you wind up with a copyWithZone: like this:
- (id)copyWithZone:(NSZone *)zone
{
Product *copy = [[[self class] allocWithZone: zone] init];
[copy setProductName:[self productName]];
return copy;
}
That works really well as long as your superclass doesn’t implement NSCopying, but if it does, you may not have enough information or access to cleanly copy it. Now you would think this would be easy:
- (id)copyWithZone:(NSZone *)zone
{
Product *copy = [super copy];
[copy setProductName:[self productName]];
return copy;
}
But that may or may not work. If super implements -copyWithZone: as described above, then all is fine. But what if your superclass uses NSCopyObject()? Things go badly, and in ways very difficult to understand and debug. Read more…
