NSOnState Is Deprecated
I’m going to discuss one change in the Objective-C API, because it is both illustrative and egregious. In the 10.14 SDK, the Objective-C constants
NSOnState,NSOffState, andNSMixedStatehave been deprecated:typedef NSControlStateValue NSCellStateValue NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValue", 10_0, 10_14); static const NSControlStateValue NSMixedState NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValueMixed", 10_0, 10_14) = NSControlStateValueMixed; static const NSControlStateValue NSOffState NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValueOff", 10_0, 10_14) = NSControlStateValueOff; static const NSControlStateValue NSOnState NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSControlStateValueOn", 10_0, 10_14) = NSControlStateValueOn;Notice that these Objective-C constants were introduced in the 10.0 SDK. They’ve been around for the entire history of Mac OS X.
This change is good even ignoring Swift because it makes the constant consistent with the vast majority of other SDK constants. This makes it more discoverable, easier to remember, and is much better and less confusing for people new to AppKit.
It seems pretty clear to me that the original Cocoa API designers made the conscious choice to put the most important and informative part of a symbol name first rather than last.
This is a legit philosophy. You may agree or disagree, but in any case it’s consistent.
It was, but they’ve been gradually reversing the order in the names since before Swift existed. In most cases I think this is for the better, although in the interim it means that Cocoa has been internally inconsistent for a long time.
The two points I would add are:
NSControlStateValueOnmay be easier to discover or understand, but it’s worse to read: longer and with the most important part at the end. Aside from the practical concerns of breaking builds, documentation, and sample code, I think renaming this commonly used constant everywhere will make the code read less well. There’s a balance to be struck between competing concerns. The same arguments in favor of this change could also apply to renamingYESto something likeNSBooleanValueYesorBOOL_YES, but I think people would agree that would not be beneficial.Adding the new names does solve some real problems, but I’m not sure that removing the old ones does. Perhaps they shouldn’t fill up the autocomplete menu, but I don’t see why they have to become compiler errors. Am I greatly bothered by this? No. I’m not personally going to be confused by this, and most of my new code is in Swift, anyway. But it does seem unnecessary.
Seriously, though, imagine a newcomer, how do they learn? A good way is to download sample code. Except the sample code doesn’t get updated frequently, so their first experience with AppKit and Objective-C is deprecation build warnings. How would you feel about that as a learner?
2 Comments RSS · Twitter
one benefit of the long-prefix names is definitely auto-complete. With NSOnState you cannot expect that autocomplete suggests anything useful. Once you start typing "On" everything is already done. If you have no clue what kind of parameter you are supposed to provide and you start typing the prefix that was already part of the placeholder, the number of suggestions rapidly shrinks, making it much easier to guess what to use.
@Karsten Yes, although this seems like a tooling issue; if the typed parameter is already there, Xcode should be able to suggest something useful.
