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.
Using the first version however only works with one argument.
mark
···
On 6/25/06, Ryan Mulligan <ryantmulligan@gmail.com> wrote:
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.
···
On 6/25/06, Ryan Mulligan <ryantmulligan@gmail.com> wrote:
Mark Van Holstyn wrote:
> being able to do...
>
> a << :arg1, :arg2
>
> is just syntax sugar for doing...
>
> a.<<( :arg1, :arg2 )
>
> Using the first version however only works with one argument.
>
> mark
Right.
The issue I have is more with the implications of that and how operator
overriding works.
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.
···
On 6/25/06, Ryan Mulligan <ryantmulligan@gmail.com> wrote:
Simen Edvardsen wrote:
> 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.
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.
···
On 25-Jun-06, at 3:58 PM, Wouter de Bie wrote:
Simen Edvardsen wrote:
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.
--
Jeremy Tregunna
jtregunna@blurgle.ca
"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..