I am basically OK with the tradeoffs involved in using autoloading in Rails. I do, however, rankle a little bit at this bit of advice in the Rails guide to developing engines.
[caption id=“attachment_4216” align=“alignnone” width=“661”]
Screencapture from Rails Guide to Engines[/caption]
In short, when configuring an engine from an initializer, you’re supposed to protect references to autoloaded application classes (e.g. models) by encoding them as strings. Your engine later constantizes the string to a class and everything is back to normal.
A thing I am not OK with is “programming with strings”. As an ideal, strings are inputs from other machines or humans and internal references to code are something else. In Ruby, symbols fill in nicely for the latter. Could I refer to classes as Symbols instead of Strings and live with the tradeoffs?
Well it turns out, oddly enough, that Rails is pretty sparing with Symbol extensions. It has only 120 methods after Rails loads, compared to 257 for String. There are no specific extensions to symbol, particularly for class-ifying them. Even worse (for my purposes), there isn’t a particularly great way to use symbols to refer to namespaced classes (e.g. Foo::Bar).
But, the Rails router has a shorthand for referring to namespaced classes and methods, e.g. foo/bar#baz. It doesn’t bother me at all.
In code I have to work with, if at all possible, I’d rather refer to classes like so:
- Refer to classes by their real ClassName whenever possible given the tradeoffs of autoloading
- When autoloading gets in the way, refer to things by symbols if at all possible
- If symbols aren’t expressive enough, use a shorthand encoded in a string, e.g.
foo/bar#baz - … (alternatives I haven't thought of yet)
- Refer to classes by their full string-y name
But, as ever, tradeoffs.
