[#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:41813] [ruby-trunk - Feature #5474] keyword argument

From: Yusuke Endoh <mame@...>
Date: 2011-12-26 14:27:04 UTC
List: ruby-core #41813
Issue #5474 has been updated by Yusuke Endoh.

Assignee changed from Koichi Sasada to Yusuke Endoh

Hello,

I've committed my patches for keyword arguments, with fixes for
some problems reported during this discussion.
Please try it and let me know if you find any problem.

This feature still requires discussion, so I'm leaving this
ticket open.

-- 
Yusuke Endoh <mame@tsg.ne.jp>
----------------------------------------
Feature #5474: keyword argument
https://bugs.ruby-lang.org/issues/5474

Author: Yusuke Endoh
Status: Assigned
Priority: Normal
Assignee: Yusuke Endoh
Category: core
Target version: 2.0.0


Hello,

I'm sending a patch for keyword arguments.

(This feature had been discussed in #5454, but I'm re-creating
 a new ticket because the old ticket was resigtered in ruby-dev)


Matz himself proposed this feature.  It is also basically
promised to include the feature in 2.0.  [ruby-core:39837]
I'm planning to commit the patch after it is reviewed by koichi.

But the detail of the spec is not fixed yet, and may be changed
drastically.
We would like to hear your comments and suggestions, especially,
with a use case and/or an actual experience.



The background of this proposal is that, in the recent Ruby,
the last argument (as a Hash) is often used to pass optional
information.  This feature is intended to aid the style.

Look an example:

    def create_point(x, y, color: "white", size: 1)
      # keyword arguments  ^^^^^^^^^^^^^^^^^^^^^^^ here!

      p [x, y, color, size]
    end
    
    create_point(2, 3, color: "red")
      #=> [2, 3, "red", 1]

The caller size is a traditional hash argument notation.
This feature is Hash parsing in the callee side.

(So it is more suitable to call it "keyword parameter."
 But I use "keyword argument" because everyone calls so.)


We can implement the similar behavior in pure Ruby.  However,
this feature is easier to read/write, and richer in the some
aspects:

- it raises an TypeError when unknown keyword is given

    create_point(2, 3, style: "solid")
      #=> unknown keyword (TypeError)

- you can use ** argument to suppress the TypeError and/or
  to get the given hash itself:

    def create_point(x, y, color: "white", size: 1, **h)
      p [x, y, color, size, h]
    end
    create_point(2, 3, style: "solid")
      #=> [2, 3, "red", 1, {:style=>"solid"}]

- it is easily used even when there is a rest argument

    def create_point(x, y, *r, color: "solid", size: 1)
      ...
    end

  (a complex and non-essential code is required to
   implement the same behavior in pure Ruby)

- there is room for optimizing the speed (though I have
  not done any optimization yet)



An alternative design is to treat all parameters as keyword
arguments (as Evan said in [ruby-core:40195]).

  def create_point(x, y, color = "white", size = 1)
    p [x, y, color, size]
  end
  create_point(color: "red", x: 2, y: 3)
    #=> [2, 3, "red", 1]

Actually I also like this, but I'm afraid if it is too flexible
and seems difficult to implement and optimize.


Thanks,

-- 
Yusuke Endoh <mame@tsg.ne.jp>


-- 
http://redmine.ruby-lang.org

In This Thread