Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Draft Proposal for Namespaces in Objective-C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft Proposal for Namespaces in Objective-C



On Apr 12, 2012, at 7:20 AM, Remy Demarest wrote:

> I would say to keep the selector namespacing for later, this is a completely different matter and I don't think you'd implement it the same way.

I agree that selector namespacing is a completely different matter, however I'd suggest that it's the one that's more important to do first.

Why do I think that?

It's already quite easy (and common practice) to namespace objects by adding a prefix to your class names without killing readability, because they're nouns:  it's not a big deal to read about ZZZDocument as a class name.  (And even if you somehow do end up with two classes being named the same thing, you'll already get a nice error telling you about it.)

	ZZZDocument *document = [[ZZZDocument alloc] init];

Theoretically it's just as easy to namespace selectors, but nobody does this in practice because it kills readability. I know I certainly don't want to write code that looks like this;

	[document ZZZAddAttachment:newAttachment];

So we end up using much more readable selectors even though they're more risky:

	[document addAttachment:newAttachment]

Now, let's say that behind the scenes (or in an OS update) Apple implements their own -addAttachment method in the underlying  frameworks.  Or ignoring the App Store perhaps they don't flag it, but both methods end up implemented on the same class and the runtime has to pick which one to use (but doesn't tell you about it) and we end up with hard-to-track-down bugs.

Adding namespaces to selectors would prevent this risk while preserving selector readability.  I can think of quite a few times where I've had to rename methods to avoid accidental method name clashes over the years, but hardly any cases of having to rename classes.

P.S. -- The above example is not just pulled from thin air, it's an actual example of a selector name I'm having to fix today:  in our last submission of OmniGraffle for iPad, we were warned that we needed to stop using private "-addAttachment:" API.  We didn't even know that Apple had any private API called -addAttachment:, we'd just implemented our own -addAttachment: method on one of our own classes and we were using that.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Draft Proposal for Namespaces in Objective-C (From: Kyle Sluder <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Kyle Sluder <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Kyle Sluder <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Jonathan Schleifer <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Kyle Sluder <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Jens Ayton <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Uli Kusterer <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Ian Joyner <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Michael Ash <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Ian Joyner <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Kyle Sluder <email@hidden>)
 >Re: Draft Proposal for Namespaces in Objective-C (From: Remy Demarest <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.