Erik,
While I agree the NS, CF, etc convention in Obj-C is the de-facto
solution for the non-namespaced nature of C in general, it is limited
since NS could just as easily be used by the the company Neanderthal
Solutions. This then forces longer abbreviation prefixes for
disambiguation. With Java, the nice thing about packages is that you
can refer to a class by its name if there is no ambiguity.
Otherwise, you provide the fully qualified name (including package).
Without namespacing, your class names are much longer. I think the
OP is really looking for a solution like modules. For instance, in
Ruby, it’s perfectly legal to create a class named Bar inside the
module named Foo. It would be written as:
class Foo::Bar
end
Then if we needed a Bar for drinking, we could create another class/
module:
class Drinking::Bar
end
Each ‘Bar’ in that case is namespaced, providing context. This is
fundamentally similar to packaging in Java, with the added benefit
that modules can also act like Categories in Objective-C by adding in
methods.
The problem as the original poster brought up is that Rails doesn’t
seem to really support this well for apps built with it (it certainly
uses it internally). There are certain benefits to the namespacing,
in addition to the distinct but identical class names it allows
providing context, you can then put classes inside subfolders
easily. ObjC doesn’t really care where the files live in folder
structures, since you simply set the source folders in your compile
settings. However, Rails convention over configuration could be a
beautiful solution if it provided better support.
Viewing a rails app with lots of classes quickly becomes overwhelming
in Textmate, since there isn’t any organization below the models
folder. XCode solves this with ObjC because you can create
artificial “groups” to organize your classes (both .h & .m) without
having to adjust compile settings, or use real folders with settings
changes.
Niels