Hi everyone,
Can someone explain me why Rails does not take full advantage of namespaces? Rails itself is divided into modules but user classes are restricted to use only names that don't coincide with existing class names with is annoying. "Transaction", for example, is a reserved name. But I find it ugly to use a name other than "Transaction" for models that really ARE "Transactions".
Erik
Erik,
Simple answer is that Ruby does not use a package system like you will find in Java. This is just something you will have to live with and learn to work around. Even in Java a "package" is really nothing more that a way of "prefixing" class names. So you just need to devise your own way of prefixing your class name, or simply take note of the reserved names in Ruby and in Rails and avoid them.
As a long time Java user. I actually don't really miss the whole packaging system imposed by Java. Especially after they added the ridiculous restriction that you cannot access objects in the "default" namespace from a class that is in a package. Now that I've been developing in Cocoa and Ruby, I have come to appreciate the simplicity of having no "packaging" system. It is no longer practical to ignore the packaging system in Java, due my previously stated restriction.
I look at it this way, when defining a Java class that is in package "com.mycompany" named "Transaction" the "real" class name is com.mycompany.Transaction. I would personally prefer just understanding that "Transaction" is a database transaction class used by Rails and would instead name my class something more descriptive like "AccountTransaction"
In any case this issue could cause a "flame war" about the practicality of package systems. That is not my intention here. You're going to find people on both sides of that fence. I happened to have found a way to jump from the Java side of the fence, to the Objective-C (Cocoa) and Ruby side of the fence.
Cocoa addresses this problem by convention. If you are creating a framework that you expect to use in your other, then the classes contained in the framework get prefixed with two capital letters. This provides some protection from naming conflicts without adding the complexity of a full packaging system. Some examples would be NSArray, NSDictionary, CIImage, etc. Where NS stands for Next Step (the operating system from which this core framework was extracted), and CI stands for Core Image (another Cocoa framework).
Ruby uses a packaging system that uses modules instead of name prefices like Java. And Rails does put different sets of logic into separate modules. I just don't see why user code should not be in a module of its own. I don't want to prefix all my models, and prefixing just one seems inconsistent. Are there any "official" articles about this topic?
Erik
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
Hi,
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).
Yes, Ruby module namespaces work the same way.
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,
With respect, I would disagree. Rails 1.2 has full support for namespaces at the model-view-controller level. You can even move your whole app/ directory into a plugin. For migrations, you can have plugins with different migration streams using PluginAWeek's excellent plugin_migrations.
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
Using Rails plugins, plus module namespaces, plus plugin_migrations lets you organise your site into distinct segments of functionality -- they call it "vertical application slices" I believe.
Have a look at Goldberg for example. It's a full web application framework with its own models, views, controllers, migrations and even routes in RAILS_ROOT/vendor/plugins/goldberg/. And all its classes are namespaced with "Goldberg::" so they don't conflict with any of your own classes.
Regards, Dave Nelson