[ruby-core:32733] Re: [Ruby 1.9-Feature#3845][Open] "in" infix operator

Hi,

2010/10/9 "Martin J. D=C3=BCrst" <[e-mail]>:
> [a, b, c] includes x, not the other way round. Of course, you can change =
the
> verb to passive voice (includ*ed*) and make the former object (x) a
> grammatical subject. But how do you expect people to deduce that you thin=
k
> about it in the passive voice from the method name 'include'?

More straightforwardly (for me), I will write:

  "is x (in) a, b or c?"  =E3=80=8Cx =E3=81=AF a, b, c =E3=81=AE=E3=81=84=
=E3=81=9A=E3=82=8C=E3=81=8B=EF=BC=9F=E3=80=8D

When we want to check whether http_method is :get or :post, is it natural
for English speaker to say:

  "do :get or :post include the http_method ?"

?


> I think that you can both say "'-' joins the array" and "the array joins
> itself with the '-'", so both Ruby and Python have a point. I think the
> awkwardness (which I feel too) is mainly because we are used to Ruby, not=
 to
> Python.

I admit it is one of the reasons of awkwardness.  But I still think the
biggest reason is the word order.  I'm curious to know whether

  ":get =3D=3D http_method or :post =3D=3D http_method"

is more natural (or equal) for you than

  "http_method =3D=3D :get or http_method =3D=3D :post"

.


>> An extreme example again: I heard that Sasada-san even created a patch f=
or
>> postpositive case statement:
>>
>> =C2=A0 p "foo" case http_request.http_method when :get, :post, :put, :de=
lete
>>
>> I believe that this shows that many people suffer from the word order
>> problem, though "in" operator is much better than this syntax :-)
>
> That case statement would in my view not be as bad as the 'in' proposal. =
The
> case statement just completes the postpositive versions of if/unless/whil=
e.
> The 'in' is a totally new construction.

That approach requires a new keyword "elscase."  And, "if" and "case" is
too exclusive; it is cumbersome to combinate normal condition and case
condition, like this:

  if (x in a, b, c) && y =3D=3D 1
    ...
  end

I believe that "case" statement is not originally designed for such a use
case.  Rather, the intended use case of "case" statement is to jump
execution to multiple "when" clauses.
I think it is better to introduce a new construction than to force to
extend "case" statement.

--=20
Yusuke Endoh <[e-mail]>