[cfe-dev] Adding namespaces to Objective-C

Ariel V Feinerman arielfeinerman at gmail.com
Thu Nov 11 05:37:56 PST 2010


Everyone strongly discourages the use "using namespace" since the objects
from tens used namespaces can clashes, well then to make short namespace
names we can use aliases, but would they clash like prefixes?


On Wed, Nov 10, 2010 at 9:52 PM, Owen Shepherd <owen.shepherd at e43.eu> wrote:

> On 10 Nov 2010, at 19:23, Ariel V Feinerman wrote:
>
> > I think prefixes are more beautiful than namespaces (by the way they are
> simple for runtime support ;-). There is no diversity between NSSet or
> NS::Set, excepting one or more unnecessary letters, so why? The namespaces
> do not increase the culture, then if prefixes can conflict so namespaces can
> likewise.
>
> Objective-C at present doesn't give you a choice. Your namespace must be
> short, or else be very cumbersome to use. Hence, everyone uses 2 character
> prefixes (or 3 at most), which are prone to clashes.
>
> On the other hand, if namespaces were supported, it is likely that NSObject
> would be called something along the lines of Foundation::Object, and other
> libraries would also use longer namespace names. This would not make
> programs any longer due to features such as "using namespace" and/or
> namespace aliases (e.g. something along the lines of C++0x's "using NS =
> Foundation", or even "using F = Foundation") and the ability to import
> entities from one namespace into another (e.g. "using Foundation::Object").
>
> My and your code will be incompatible if we choose NS, N, or something
instead of Foundation:: We increase issues and look how we can  eliminate
them.


> Namespaces give us the ability to have longer entity names, without the
> inconvenience this would normally cause.
>
> -- Owen Shepherd
> http://www.owenshepherd.net/
> owen.shepherd at e43.eu (general) / oshepherd1 at shef.ac.uk (university)
>
>


-- 
best regards
Ariel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101111/1b8e8418/attachment.html>


More information about the cfe-dev mailing list