Hi –
On Mon, 15 Jan 2007, Andrew S. wrote:
expect this is an artifact of the Ruby language itself. As Rails extends the
concepts, this is way beyond my coding skills for now.
You’re touching on several different, though in some ways similar,
things here.
Ruby’s reserved words – if, def, and, class, and so forth – are
probably best not used as table or column names. They’re not method
names (though one of them, class, is also the name of a built-in
method; its dual nature causes minor problems in Ruby already). But
you’ll still probably have cause to regret naming a column “not” or
“then” or “true”…
You can see a complete list of Ruby keywords in the file keywords in
the top level of the Ruby source tree.
So that’s reserved words. To be avoided, but no big loss as they’re
weird names for tables anyway. Then there are methods.
Methods names that cause these blow-ups in Rails are either:
- built-in Ruby methods, or
- Rails methods
An example of the former is “display”. If you name a controller
action “display”, you’ll get a rather cryptic error to the effect that
there’s no such action. That’s because (as I understand
action_controller/base.rb) “display” is a built-in Ruby method and it
gets masked out, along with the controller object’s other existing
methods, as a candidate action name. If you were allowed to name an
action display (or inspect, or method, etc.), then the original method
would be hidden from the object. You could detect that there was an
override and try to circumvent it – but, aside from being very slow,
that would still leave the question of how you’d know which method was
wanted. Presumably sometimes you’d want the new one, and sometimes
the old one.
An example of blow-up method type #2 is “transaction”, the one you
mentioned. Ruby isn’t involved here; that’s purely a matter of Rails
defining a method and then a user-defined method overriding it. I
don’t think there’s much to do about this case either. If you name a
column “attribute” or “reload” or “save”, you’re changing what the
message means to the object and making it, I think, literally
impossible to know unambiguously what obj.reload (or whatever) is
supposed to mean.
It’s all a bit of an obstacle course, but in the long run the number
of options that get ruled out is fairly small.
David
–
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (Ruby for Rails)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)