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;
So we end up using much more readable selectors even though they're more risky:
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