Ruby expects 2 arguments instead of one (which is right).
But when doing:
s.<< “1”, “2”
suddenly everything works. To me, this seems a bit weird, since I
expected that s << is syntactic sugar for s.<<, but the implementation
seems different. Also using <<(*args) in the method definition doesn’t
do what I expect it to do. Of course I can work around not using s <<
with multiple arguments, but I’m just curious what the design principles
are behind this behaviour.
The discrepancy here bothers me, because all of the Ruby tutorials I
have read talk about how you can override operators, but really it is
only half true. You can only overide the logic of the operator but not
it’s arity. This seems unacceptable in my conceptual model of the
language, despite the problems with grammar that Logan Capalado brought
up on the IRC chat.
It’s syntactic sugar. You can’t expect it to work with arbitrary
arities. It’s a bit like complaining that you can’t to `1 + 2, 3’ in
Ruby. << makes sense with one argument. You know that it really just
masks an method call. If you are so comfortable with Ruby that you
understand what is a method call and what’s not, having to use the
method call syntax shouldn’t be that difficult.
Remember, Ruby has lots of more syntax than, say, Smalltalk, but at
its core the semantics are, if not as simple, close.
It’s syntactic sugar. You can’t expect it to work with arbitrary
arities. It’s a bit like complaining that you can’t to `1 + 2, 3’ in
Ruby. << makes sense with one argument.
My complaint lies more in the fact that most ruby documentation I have
read, doesn’t tell you the whole story about operator orriding. They say
you can do it, but they neglect to tell you that your syntatic sugar
will fail if you want your operator to have a different arity.
That’s because operator overriding isn’t an extension of the
semantics, but the syntax. Perhaps the documentation ought to make
that clear.
I agree with that. The documentation should note that << only overloads
or defines the method called “<<”, but does not overloads or redefines
the syntax of <<. Ofcourse the same goes for other operators like + and
-. On the other hand, ruby only gives a syntax error when calling the
method and doesn’t warn the programmer when defining the method. I think
it’s logical that ruby warns when programmer when the method is defined,
since the example I give on top is completely unuseful.
-. On the other hand, ruby only gives a syntax error when calling the
method and doesn’t warn the programmer when defining the method. I
think
it’s logical that ruby warns when programmer when the method is
defined,
since the example I give on top is completely unuseful.
Why would you want it to warn you when you’re defining it? You assume
that it’ll know how you want to use it, which it cannot know that.
“One serious obstacle to the adoption of good programming languages
is the notion that everything has to be sacrificed for speed. In
computer languages as in life, speed kills.” – Mike Vanier
Why would you want it to warn you when you’re defining it? You assume
that it’ll know how you want to use it, which it cannot know that.
In the case above, I cannot use the method in any way. Not with one and
not with multiple arguments. Shouldn’t be too hard to figure out that
this method can not be used…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.