4 ms·
> And yet, Apple still use NSCopyObject themselves to this very day On one hand, I'm not surprised. Change at that low a level is danger. The most risk-averse
by JKCalhoun 2y ago
> And yet, Apple still use NSCopyObject themselves to this very day
On one hand, I'm not surprised. Change at that low a level is danger. The most risk-averse path is probably what Apple did: leave the classes calling NSCopyObject() alone, and really really warn developers not to use it (and be sure not to introduce any new Apple classes that call it). (The author raises the obvious problem though with subclassing ... would be embarrassing for Apple to also tell devs to stop subclassing NSCell)
I think with how dynamic the OS has shown itself to be, we generally hope that problems like this just "go away". Apple is probably hoping people, decades on now, are no longer subclassing NSCell — have moved off of NSAnimation....
Interesting read. I always like to learn how things work under the hood.
It's a funny thing that when you are introduced to a new language or framework — like ObjectiveC and Cocoa were to me, it feels like a thing that works in a magical way. And initially you treat it like the black box it appears to be. You adhere to things you are told like, call AutoRelease() before returning an object if you expect the caller to retain or whatever - not really knowing what all that means. Only later finding out that the "magic" of retain/release is just a count that is incremented and decremented.
In time the veneer of magic fades and you remind yourself that the thing was written in C after all.
- jwells89 2y agoI doubt there’s too many people subclassing NSCell directly these days, but unless I’m missing something (entirely possible), it’s difficult to avoid subclassing NSButtonCell in a lot of cases where you want a stock yet lightly customized control. That’s where I’d expect to see the bulk of third party NSCell subclassing.
- chuckadams 2y ago> Only later finding out that the "magic" of retain/release is just a count that is incremented and decremented. Pretty sure most devs know that's what reference counting ultimately boils down to (it's right in the name after all), but many papers over the decades testify to the fact that maintaining that counter in a way that's both fast and reliable turns out to be surprisingly tricky.