[#41431] [ruby-trunk - Bug #5694][Open] Proc#arity doesn't take optional arguments into account. — Marc-Andre Lafortune <ruby-core@...>

27 messages 2011/12/01
[#41442] [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Thomas Sawyer <transfire@...> 2011/12/01

[#41443] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Yehuda Katz <wycats@...> 2011/12/01

Maybe we can add a new arity_range method that does this?

[#41496] [ruby-trunk - Bug #5714][Open] Unexpected error of STDIN#read with non-ascii input on Windows XP — Heesob Park <phasis@...>

22 messages 2011/12/06

[#41511] [ruby-trunk - Bug #5719][Open] Hash::[] can't handle 100000+ args — Nick Quaranto <nick@...>

13 messages 2011/12/07

[#41557] [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong — Yukihiro Matsumoto <matz@...>

14 messages 2011/12/08

[#41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords — Martin Bosslet <Martin.Bosslet@...>

17 messages 2011/12/10

[#41672] [ruby-trunk - Feature #5767][Open] Cache expanded_load_path to reduce startup time — Yura Sokolov <funny.falcon@...>

13 messages 2011/12/15

[#41681] Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...>

Since Ruby is built on top of simple concepts, most of the documentation

23 messages 2011/12/15
[#41683] Re: Documentation of the language itself (syntax, meanings, etc) — Gary Wright <gwtmp01@...> 2011/12/15

[#41686] Re: Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2011/12/16

Em 15-12-2011 19:23, Gary Wright escreveu:

[#41717] Feature : optional argument in File.join — Michel Demazure <michel@...>

In Windows, when using File.join, one often ends with a path containing

13 messages 2011/12/19
[#41719] Re: Feature : optional argument in File.join — Luis Lavena <luislavena@...> 2011/12/19

On Mon, Dec 19, 2011 at 6:09 AM, Michel Demazure <michel@demazure.com> wrote:

[#41720] Re: Feature : optional argument in File.join — Michel Demazure <michel@...> 2011/12/19

Luis Lavena wrote in post #1037331:

[#41728] [ruby-trunk - Feature #5781][Open] Query attributes (attribute methods ending in `?` mark) — Thomas Sawyer <transfire@...>

15 messages 2011/12/19

[#41799] Best way to separate implementation specific code? — Luis Lavena <luislavena@...>

Hello,

15 messages 2011/12/24
[#41800] Re: Best way to separate implementation specific code? — KOSAKI Motohiro <kosaki.motohiro@...> 2011/12/24

2011/12/24 Luis Lavena <luislavena@gmail.com>:

[#41811] Re: Best way to separate implementation specific code? — "U.Nakamura" <usa@...> 2011/12/26

Hello,

[#41817] Re: Best way to separate implementation specific code? — Luis Lavena <luislavena@...> 2011/12/26

On Sun, Dec 25, 2011 at 10:51 PM, U.Nakamura <usa@garbagecollect.jp> wrote:

[#41812] [ruby-trunk - Feature #5809][Open] Benchmark#bm: remove the label_width parameter — Benoit Daloze <redmine@...>

11 messages 2011/12/26

[ruby-core:41602] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account.

From: Yukihiro Matsumoto <matz@...>
Date: 2011-12-12 03:51:13 UTC
List: ruby-core #41602
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.  I know it's a vague definition.  But too
strict rule did not run community well in the past.

|As I've tried to detail my evaluation criteria, if there is no sign of intent, I do not consider it an "incompatible change". Noone has shown any sign of intent with respect to the arity bug. What justification do you have to call this an "incompatible change"?

I agree we have at least one bug in arity.

    def Object.foo(a=42); end
    foo = Object.method(:foo).to_proc
    bar = ->(a=42){}
    foo.arity == bar.arity # => false

should be true.

Also, I think we need to update the documentation.  After defining
consistent "right" definition.

|We've had #arity return -n-1 whenever there are optional arguments or "rest" arguments for the past 11 years. I'm honestly still surprised I even have to convince anyone and that a discussion is needed. This is the big lesson I'll get from this; I will try not to assume that obvious bug fixes are obvious anymore.

Thank you for finding inconsistency.  Now we need to fix up the
desirable behavior.  First I thought to keep the original arity
behavior, but after investigating the behavior, both Method#arity and
Proc#arity have weird corner cases.

My idea for new behavior is:

 * arity ignores all optinal arguments
 * arity returns -n-1 if there's rest argument
 * where n is number of mandatory arguments

 * we might need to add arity_max that honors optinal arguments, or
   existing #parameter may be good enough.

Any opinion?

							matz.

In This Thread