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

From: Marc-Andre Lafortune <ruby-core-mailing-list@...>
Date: 2011-12-22 04:55:15 UTC
List: ruby-core #41772
Hi,

Not sure why the following modifications made in redmine were not
posted on the mailing list...

While having fun testing your patch, I encountered an issue with more
than 2 rest arguments:

    def foo(*rest, b: 0, **options)
      [rest, options]
    end

    foo(1, 2, bar: 0)  # => [[1, 2], {bar: 0}]  OK
    foo(1, 2, 3, bar: 0)  # => [[1, 2, {bar: 0}], {bar: 0}]  Not OK


On 30 October 2011 11:10, Yusuke Endoh <mame@tsg.ne.jp> wrote:
> Currently, my patch allows ** only when there are one or more
> keyword arguments.
>
> This is because I didn't think of any use case.
> In addition, I wanted to simplify the implementation of parser.
> (Unfortunately, adding a new argument type requries *doubling*
>  the parser rules to avoid yacc's conflict)
> Do you think we need it?

I'm worried about cases where one doesn't use named arguments directly
but wants to pass them on to another method.

Let's say we have a Gem that defines:

  def import(*files, format: :auto_detect, encoding: "utf-8")
    # ...
  end

Say one wants to implement a variation of this that prints out a
progression. If it was possible to have a ** arg, one could:

  def my_import(*files, **options)
    puts "Importing #{files.size} files: #{files}"
    import(*files, options)
  end

A new version of the gem can modify the method `import` by adding
options, or changing the default of any option, add options and
`my_import` would work perfectly.

But if we can't define it this way, we have to do some artificial hoop
jumping. Either:

  def my_import(*files, format: :auto_detect, encoding: "utf-8")
    puts "Importing #{files.size} files: #{files}..."
    import(*files, format: format, encoding: encoding)# ...
  end

Downsides: verbose, won't pass on any new options, default changes
won't be reflected

  def my_import(*files, format: :auto_detect, **options)
    puts "Importing #{files.size} files: #{files}"
    import(*files, options.merge(format: format))# ...
  end

Downsides: verbose, format looks like a special option and if its
default changes in the Gem, it won't be reflected, but others will

  def my_import(*args)
    files = args.dup
    files.pop if files.last.respond_to?(:to_hash)
    puts "Importing #{files.size} files: #{files}"
    import(*args)
  end

Downside: `*args` less clear then `*files, **options`, slower, verbose, ...

I feel that the first (currently illegal) version is the much nicer
than the alternatives.

> I didn't implement caller's **.
> I wonder if we need it or not.  Is "other(a, h)" not enough?

I think one reason to have it is to avoid calling Hash#merge when
combining options, like in the above examples.

Instead of

    def foo(bar: 42, **options)
        baz(extra_option: 1, **options)
    end

Currently, one has to do:

    def foo(bar: 42, **options)
        baz(options.merge(extra_option: 1))
    end


Benoit Daloze wrote:
> 2) I'm a bit dubious about the `**h` syntax to get (and I guess to pass) a Hash though.
> ...
> Something related to `{}`, the literal Hash syntax, would fit better in my opinion.
>
> Do you have any idea of an alternate syntax to `**h` ?

I haven't given much thought, but here's an alternate suggestion,
where **h => {*h}:

    def foo(a, b=1, *rest, {c: 2, d: 3, *options})
    end

If the parser allows, the {} could be optional, at least in the case
without a "hash-rest" argument.

This could actually be two new concepts that could be used everywhere
in Ruby (not just for argument passing):
a) Splat inside a hash does a merge, e.g.

    h = {foo: 1, bar: 2}
    {*h, baz: 3} # => {foo: 1, bar: 2, baz: 3}

I'm not sure if it should be silent in case of duplicate key (like
`Hash#merge` with no block) or if it should raise an error.

b) Hash destructuring, e.g.:

    h = {foo: 1, bar: 2}
    {foo: 42, extra: 0, *rest} = h
    foo   # => 1
    extra # => 0
    rest  # => {bar: 2}

It would be nice to not need a default:

    {foo, extra, *rest} = h
    extra # => nil

This could be allowed in arguments too:

    def foo(a, b=1, *rest, {c, d, *options})
    end


What do you think?

In This Thread