Tue, Nov 2, 2010, 3:34pm Off-Limits Class Names in Cocoa
Programming » Cocoa
(Last updated: Wed, Nov 3, 2010, 3:25am)
I
just wanted document somewhere on the internet unprefixed object names in the Objective-C runtime that could potentially trip you up. I'm just talking about capitalized words, not C keywords, and I'm not talking about anything already given a namespace prefix like the NS* types.

There are un-prefixed, capitalized type names lurking in the runtime.

But surely one should always prefix one's own class names to ensure a clean namespace, right?

Well, that's surely a safe practice, but not usually what coders do in their own private classes. If you are publishing your classes, say, in a public framework, then for sure make all the classes in their in a safe namespace-prefixed naming scheme, since Obj-C has a flat namespace.

But in your own code, people usually just name objects without prefixes. Little of Apple's sample code prefixes. (I have a huge archive of such sample code that I had awk'd to check.) And few if any books do it when walking you through their example code.

There's nothing wrong with not prefixing object names in one's own code, as long as you know what reserved names to step around, hence this entry. If you stick to the standard CamelCase convention for object names, you can basically treat the non-prefixed namespace as your own playground. With the following exceptions.

Class is perhaps the most obvious, and is a perfectly reasonable core reserved word used to make all the other objects. There's also a little bit of legacy history known as Carbon, and it haunts your class name choices in the form of MacTypes.h, which includes this list of typedefs, all of which mean you can't use them for object names. NeXT-inherited typedefs did not use CamelCase, but pre-NeXT Apple did, so here's a convenient list of such reserved names. Note that most of them would be terrible class name choices anyway:

CCCCC
AbsoluteTime
Boolean
Byte
ByteCount
ByteOffset
BytePtr
CharParameter
CompTimeValue
ConstLogicalAddress
ConstStr15Param
ConstStr255Param
ConstStr27Param
ConstStr31Param
ConstStr32Param
ConstStr63Param
ConstStrFileNameParam
ConstStringPtr
Duration
Fixed
FixedPoint
FixedPtr
FixedRect
Float32
Float32Point
Float64
Float80
Float96
FourCharCode
Fract
FractPtr
Handle
ItemCount
LangCode
LogicalAddress
NumVersion
NumVersionVariant
NumVersionVariantHandle
NumVersionVariantPtr
OptionBits
OSType
OSTypePtr
PBVersion
PhysicalAddress
Point
PointPtr
ProcessSerialNumber
ProcessSerialNumberPtr
ProcHandle
Ptr
Rect
RectPtr
RegionCode
ResType
ResTypePtr
ScriptCode
ShortFixed
ShortFixedPtr
SignedByte
Size
Str15
Str255
Str27
Str31
Str32
Str32Field
Str63
StrFileName
StringHandle
StringPtr
Style
StyleField
StyleParameter
TimeBase
TimeRecord
TimeScale
TimeValue64
TimeValue
UniChar
UniCharCount
UniCharCountPtr
UniCharPtr
UnicodeScalarValue
UniversalProcHandle
UniversalProcPtr
UnsignedFixed
UnsignedFixedPtr
UnsignedWide
UnsignedWidePtr
UTF16Char
UTF32Char
UTF8Char
VersRec
VersRecHndl
VersRecPtr
WidePtr


Several of these names I could see someone wanting to use and being confused about why they were denied.

(A mere few months ago, there were 3 others that were off limits: Protocol, Object and List (!). They are now all ok to use, at least as of the SDK I've got installed.)

Safest approach: Prefix all your object names.
Regardless: Be aware of these namespace collision possibilities (i.e., the above chart).

Other such types I should be aware of? Differences between iOS and OSX?

Leave a comment