"Would we say that operators, methods, and messages aren't first class entities?"
No, the deal is that '+', '*', etc aren't some special "operator" type
in Ruby, they're just methods. The parser is what makes them look like
traditional operators. So "x + y" is calling the '+' method on 'x', and
passing 'y' as a parameter.
So in saying "x some_daynamic_stuff y" you're probably thinking "that
should come out looking like 'x + y', so it should work.".
The problem, is that to ruby it looks like: "Object1 some_method
When you use symbols such as +, -, *, /, etc, the parser just pretends
you have a '.' there, so to you 'x + y', but to Ruby, 'x.+(y)'.
Except the parser can't make this magic the way you're trying, because
you're trying to execute it to see a result; something that happens
_after_ parsing. So to ruby your method looks malformed. It's easier to
see if instead of a '+' or '*' method, we use something else: 'Greg'
See, 'Greg' isn't the reciever for 'to_i'. There's no '.' to tell it
so. This is what you're ending up with. The 'send()' syntax mentioned
earlier is a way to specify the reciever.
I would definitely consider methods "first-class" citizens in Ruby. The
trick is that parenthesis in Ruby are optional. So unlike some
var meth = "Greg".toString;
Which would assign the value of the toString member of "Greg" to a
variable called "meth", in Ruby this would actually execute the
"toString" method. Because parens are optional. So to refer to a method
without executing it, you'd use:
meth = 'Greg'.method(:to_s)
Which would return a BoundMethod, which has methods and attributes of
it's own. So they're definitely objects. It's just that getting a
handle on the object is made a little difficult since accessing the
member directly executes it, parens or no parens.
So you have a choice: Always force the use of parens for method calls,
or have a helper for reflection so parens can be optional. Ruby chose
the latter, (and I definitely think it was the right choice).
Sorry for going on so long...