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 9, 2012, at 7:25 PM, Ian Joyner wrote:

Just to throw in a different thought line to think along... do we really need namespaces in the language at all?

Isn't the problem to avoid ambiguity of a single name referring to two or more different entities? Seems this is more an organizational issue and maybe handling organizational issues in the language makes the language much more complex. Should such organizational issues be pushed out to either the compiler or the IDE or a combination of the two?

The problem is to not only avoid that ambiguity when writing code, but also avoid it at runtime. Having a single namespace means all sorts of problems for binary compatibility.

For example, say I build an array class. Being a good citizen, I prefix it with my initials, so it's MAArray. (Note that this is already a primitive, manual form of namespacing.) For the next OS release, Apple releases a framework called MacAttack which has its own array class with the same name. Hilarity ensues.

We need some way to ensure that names are, within reasonable certainty, *universally* unique. For example, by using reverse-DNS on the names like com.mikeash.Array, which we know will never conflict with anything Apple puts out.

We can sort of do that now. I could name my class ComMikeashArray instead of MAArray. But this is really ugly and cumbersome.

The IDE could help with that, of course. It could have some kind of internal namespace system where it only shows me "Array" but actually splats ComMikeashArray into the source code. The trouble with that is that you now have a major difference between what the IDE displays and what the compiler sees, which I imagine will lead to all sorts of nastiness. It would sort of be like the C preprocessor, except not standardized, not nearly as well understood, far more commonly used, bidirectional, and running at the wrong time.

Since that ends up effectively being a preprocessor, we could just make an actual preprocessor. The programmer would write files that use namespaces, the preprocessor translates them into non-namespaced Objective-C code, and then the compiler compiles that. This would work fine, but you've now basically just created a new language that happens to share a lot with Objective-C. If you've done that, you might as well go all the way and actually integrate these changes into Objective-C.

Maybe I've missed some nice way to have the IDE disambiguate things, but it seems to me that namespaces are something Objective-C really needs in the language.

Mike


 _______________________________________________
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>)



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.