You, and a number of other people, have made some great points. It's awesome to have so many of my beliefs and ideas corrected, challenged, or just put into a new, wider perspective. But it's even more awesome (if painful for me ;) it can be done in public, where thousands of would-be Cocoa programmers can watch. You know more than a few people are thinking the same things I am, wondering what the hell good is NSCell and things like that. A few of the comments people have made about the collection classes have demonstrated, to me, and to those watching at home, of some of the awesomeness of Objective C.
That said, I might not have made myself entirely clear on a few points. When I say the interface is broken, I don't mean compared to other frameworks. I want to make clear that my entire post is entirely within the given that Cocoa is wonderful and closer to perfection than any other. That said, let's get brutal. In other words, we know Cocoa is a 9.x, so let's debate the X. If I say a feature rates a 2, I mean it rates a 9.2. That's good, but it's the shitty side of good, if you know what I mean.
Also, the coffee at Zoka is not too weak. It's just kind of burnt, like all the coffee in Seattle. Apparently in order to save coffee, Seattle had to destroy it. Yecch.
I don't think opacity is evil, but I do think it's potent and dangerous magic that we have to be very careful not to abuse. As I say in the post, Core Data probably has to have the level of opacity it has because of the level of abstraction it provides. The proxy objects in NSTreeView on the other hand? Yet to see any explanation that isn't strained carrots and bullshit.
You're right that operating around the edges is always tricky, but that doesn't mean I can't wish the edges were move out a little further. Especially with Leopard I see a lot of demo-design, where a certain class of obvious general use makes so much sense when you use it exactly like the demo, but as soon as you try to apply it to a real problem, you quickly realize its harsh limitations. Again, I have to point to the tree view on this. Bad, wicked, naughty tree view. Bad!
You're also right that shadow files don't literally negate the purpose of Core Data as an object model. Certainly the performance of a database is a big win. But, it does take big chunks of Core Data as a persistence model, Core Data as a time-saver for developers, and so forth. Yes, the purpose of frameworks is take us away from all this, but when frameworks collide, it's ugly for all of us. Garbage collection, meet Core Graphics. Crash. Suck. Bye.
Finally, I don't want to merge all the collections together. I just think that they do have a lot in common, and it would be nice to be able to decide at runtime (or trivially at design time) to change collection types without giving up type checking. A set is different from an array, but way more different than a string. I think the idea of a collection is a thing in and of itself.
And now, if you'll excuse me, I have to go work on some LOLhats.
by Mike Lee — Nov 07
That said, I might not have made myself entirely clear on a few points. When I say the interface is broken, I don't mean compared to other frameworks. I want to make clear that my entire post is entirely within the given that Cocoa is wonderful and closer to perfection than any other. That said, let's get brutal. In other words, we know Cocoa is a 9.x, so let's debate the X. If I say a feature rates a 2, I mean it rates a 9.2. That's good, but it's the shitty side of good, if you know what I mean.
Also, the coffee at Zoka is not too weak. It's just kind of burnt, like all the coffee in Seattle. Apparently in order to save coffee, Seattle had to destroy it. Yecch.
I don't think opacity is evil, but I do think it's potent and dangerous magic that we have to be very careful not to abuse. As I say in the post, Core Data probably has to have the level of opacity it has because of the level of abstraction it provides. The proxy objects in NSTreeView on the other hand? Yet to see any explanation that isn't strained carrots and bullshit.
You're right that operating around the edges is always tricky, but that doesn't mean I can't wish the edges were move out a little further. Especially with Leopard I see a lot of demo-design, where a certain class of obvious general use makes so much sense when you use it exactly like the demo, but as soon as you try to apply it to a real problem, you quickly realize its harsh limitations. Again, I have to point to the tree view on this. Bad, wicked, naughty tree view. Bad!
You're also right that shadow files don't literally negate the purpose of Core Data as an object model. Certainly the performance of a database is a big win. But, it does take big chunks of Core Data as a persistence model, Core Data as a time-saver for developers, and so forth. Yes, the purpose of frameworks is take us away from all this, but when frameworks collide, it's ugly for all of us. Garbage collection, meet Core Graphics. Crash. Suck. Bye.
Finally, I don't want to merge all the collections together. I just think that they do have a lot in common, and it would be nice to be able to decide at runtime (or trivially at design time) to change collection types without giving up type checking. A set is different from an array, but way more different than a string. I think the idea of a collection is a thing in and of itself.
And now, if you'll excuse me, I have to go work on some LOLhats.