Tue, Nov 2, 2010, 3:34pm
Off-Limits Class Names in Cocoa
Programming » Cocoa
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:
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?
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:
| 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 | CCCCC
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?