From: Marc-Andre Lafortune <ruby-core-mailing-list@...>
Date: 2011-12-18T04:54:30+09:00
Subject: [ruby-core:41708] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.

Hi,

On Sun, Dec 11, 2011 at 10:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: [ruby-core:41600] [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account."
> � �on Mon, 12 Dec 2011 11:30:26 +0900, Marc-Andre Lafortune <ruby-core@marc-andre.ca> writes:
>
> |Yukihiro Matsumoto wrote:
> |> We are not going to add incompatible changes to trunk, ...
> |
> |Could you please explain to me what difference you see between an "incompatible change" and any "bug fix"?
>
> Good point. �It's whether the change makes difference from intention
> of the original designer. ...

So do we agree that my patch is not an incompatible change?

>�First I thought to keep the original arity
> behavior, but after investigating the behavior, both Method#arity and
> Proc#arity have weird corner cases.

Apart from the one I'm pointing out (which is only present in Ruby
1.9), what other corner cases are there? In particular, is there any
corner case in the 1.8 line?

> My idea for new behavior is:
>
> �* arity ignores all optional arguments
> �* arity returns -n-1 if there's rest argument
> �* where n is number of mandatory arguments
>
> Any opinion?

Can you explain what would be gained by this new behavior, i.e. how is
this change more helpful than the current behavior?

Also, can you explain why you consider that breaking the previous
behavior would be a good idea?

A quick check for uses of `arity` in Rails reveal that the typical use
looks like "does this method use only 1 parameter or can it use more
than that?"

Among other things, this change could break many Rails app.

Moreover, Rails and any other gem using `arity` would have to jump
through hoops to maintain a compatible version with Ruby 1.8.7 (which
doesn't have the `parameters` method) and Ruby 1.9.2+.

Finally, assuming you decide to go forward with this feature change
for Ruby 2.0, shouldn't the 1.9 line still be fixed with my patch to
be consistent?

Thanks