Re: Draft Proposal for Namespaces in Objective-C

Part of my unease is that the disambiguation in other languages I have seen (like Java) occurs in the code all over the place, particularly with com.mikeash.Array. Really, the dots (.), might look like some kind of multi-level name, but in actual fact are just part of a longer name.

A single point of decision would be much cleaner, like a single piece of meta syntax saying

use array from com.mikeash

or with renaming

use array from com.mikeash as maarray

I don't really like that except in the same module you might want to use

use array from com.macattack as attack_array

And I have never liked the naming scheme NS.... as a primitive namespace either!

The use directives I think can be passed as a compiler directive so the compiler sorts this out, but in such a way as it has not impacted the pure computation of the code. Because this might be a reasonably complex form of compiler directive it could be a separate specification file which has to do with the assembly (not to be confused with assembler) of the whole system.

Ian

On 10 Apr 2012, at 09:44, Michael Ash wrote:

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)

This email sent to email@hidden

 _______________________________________________
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