Mike Lee on Cocoa

Mike Lee of Delicious Monster has a post on things he'd like to see changed in Cocoa. I agree with some of what he says, but I think some parts of the frameworks he's critical of make more sense in context.

For the most part, I agree with the comments about things being returned by indirection and not relying on NSCell so much. In fact, I think Cocoa is already heading towards using views more liberally, in that NSCollectionView seems to be moving into the space previously occupied by NSMatrix.

Anyway, here's where things start to get a bit fuzzy:

Leopard unified the user interface, but the application programming interface remains as broken as ever.

What now? The air is too thin up north. But seriously. You're nuts. No, I really mean it. The coffee at Zoka must be too weak.

As broken as ever? Can you point me to a desktop API that makes Cocoa look broken by contrast? I'm not saying it's perfect by any stretch — and what is — but "broken" has a much different meaning than "imperfect."

NSFormatter is older than Lucas

Classic.

Apple: there's one engineering team that has an inexplicable hard-on for opaque proxy objects

I disliked opaque private API for a long time, then I realized something. If you introduce public API, you're expected to support it until the end of time. So unless you're ready to have it written in stone, it's better to keep it private. It's not a perfect solution, just a compromise.

Which brings me to Core Data. For the record, I adore Core Data, but it [...] does hijack a lot of NSObject�s methods, declaring them off limits, which succeeds in limiting its usefulness, mucking up the interface, and sending us into the documentation.

It succeeds in limiting what you think would be useful. It's possible that if Core Data was implemented without blocking you off from any of the normal patterns, you'd end up with something that was much easier to use but extremely slow and inflexible. As it stands, Core Data in Leopard is ridiculously fast if used properly.

I've actually written a persistence engine with SQLite before. It was my first real Cocoa project. Nothing on the scale of Core Data, but even in its relatively humble means, it was incredibly difficult to satisfy both ease-of-use and performance. My approach was very much like what you describe — use normal NSObjects, allow all of the normal patterns, and handle everything on the framework end.

If I was to start from scratch and now and do it all over again, this is the first part I would change. From what I've seen, trying to do a scalable persistence engine without "special" objects is just a mess. Apple's engineering team has, in one form or another, been at this particular task for something around fifteen years.

The list of things not to subclass or override is enormous. Dire warnings about intricate optimizations and object life-cycle management send a very clear message: trust us. Abandon all control over your objects and give yourself to Core Data.

Basically, yes. But that's the case for Cocoa in general. In fact, that's really the point of a framework. The idea is to express what you want done and be abstracted away from as many of the details as possible. This gets more complicated when you hit edges cases, but that's the just the nature of programming.

and maybe they really do need to take over the object life cycle, given the concept of faulting versus normal deallocation

Pretty much. The alternative is to have the application take days to load all of its data or run out of address space.

to give up control of your objects for all that Core Data gives you for free, but opacity breeds inflexibility

I completely disagree. If you didn't want an opaque implementation, you'd be using raw SQLite APIs. The reason Core Data is interesting is that you don't have to worry about all the details. Depending on specific implementation details breeds inflexibility. If one of those details changes, your application snaps in half. It's shades of grey, of course.

and when you run into the limits of what Core Data can do, things start to get very, very tricky

That's true for just about anything. If you run into the limits of what video hardware can do, it's not a walk in the park. You have to change strategies.

In fact, this is the whole point. Core Data needs to perform well on a wide range of hardware, so it takes a strategy of abstracting you from the engine. If it didn't, the complicated logic for faulting and caching would just move from the framework to your application.

The trouble is, writing out a bunch of files kind of negates the whole point of using Core Data, because writing and maintaining two different data stores takes time.

It makes it more complicated, I agree. It does not negate it, though. If it did, you'd just been storing all of your data in individual files. The on-disk files are basically a secondary cache, but having everything in a database means access is much, much faster.

Finally, why are collections mutually exclusive of one another?

They don't all behave the same. For example, NSSet doesn't allow duplicates, but the others do. So if you had twenty objects in an "array" NSCollection (of which ten are duplicates) and copied them to another NSCollection, you might wonder why you just lost half of your objects. Only later do you discover that the collection happened to be a NSSet. It might also be frustrating to learn your objects suddenly had lost their order because NSSet and NSDictionary have no inherent order to their contents.

I think merging all of these together would just lead to more confusion. In reality, there are only three main collection types. That's nothing.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.