Ruby-dev summary 23566-23622

ruby-talk
1

Hello,

The following is a summary of ruby-dev.

ruby-dev:23566-23622

[ruby-dev:23616] [Oniguruma] Version 3.1.0 and 2.2.9

Kosako announced the new release of Oniguruma, which is a regular
expression matching engine working with ruby.

[ruby-dev:23572] keyword argments (Ruby2.0 spec)

Nagai asked how keyword arguments and hash-style arguments work in
ruby-2.0, since a lot of hash-style arguments appear in his extension
library ‘Ruby/Tk’. Matz proposed following two solutions.
(a) hash-style argument appearing at the end of argument list is
supported as usual.
(b) hash-style arguments were abolished.
Nagai chose a case for (b) because of rapid shift to ruby-2.0.

[ruby-dev:23567] for smoother extending PStore

Nishiyama posted a patch for smoother extending PStore#dump and
PStore#load. This change is useful for implementation of YAML::Store.

···

–
Takaaki Tateishi ttate@ttsky.net

2

[ruby-dev:23572] keyword argments (Ruby2.0 spec)

Nagai asked how keyword arguments and hash-style arguments work in
ruby-2.0, since a lot of hash-style arguments appear in his extension
library ‘Ruby/Tk’. Matz proposed following two solutions.
(a) hash-style argument appearing at the end of argument list is
supported as usual.
(b) hash-style arguments were abolished.

I’d prefer (a), because backward-compatibility is a good thing, and I’d
prefer to change my code as little as possible to make it work on Ruby
2.0.

But how would (a) work? It seems like it would make the following
ambiguous:

def foo(foo, bar=2)
end

foo(:foo => 14, :bar => 92)

(is this calling foo with a hash and leaving bar with default argument,
or is it calling foo with foo equal to 14 and bar equal to 92?)

If (b) is chosen, it would be nice if hash-style arguments were
deprecated for a version between current and 2.0.

Nagai chose a case for (b) because of rapid shift to ruby-2.0.

I don’t understand. What is meant by “rapid shift to ruby-2.0”?

Paul

···

On Thu, Jun 03, 2004 at 12:00:51AM +0900, Takaaki Tateishi wrote:

3

Hi,

···

From: “Takaaki Tateishi” ttate@ttsky.net
Subject: ruby-dev summary 23566-23622
Date: Thu, 3 Jun 2004 00:00:51 +0900
Message-ID: 3666.61.23.130.160.1086188445.squirrel@61.23.130.160

[ruby-dev:23572] keyword argments (Ruby2.0 spec)

Nagai asked how keyword arguments and hash-style arguments work in
ruby-2.0, since a lot of hash-style arguments appear in his extension
library ‘Ruby/Tk’. Matz proposed following two solutions.
(a) hash-style argument appearing at the end of argument list is
supported as usual.
(b) hash-style arguments were abolished.
Nagai chose a case for (b) because of rapid shift to ruby-2.0.

I chose the solution (a) at [ruby-dev:23624]. :slight_smile:

                              Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)
4

Paul Brannan wrote:

[ruby-dev:23572] keyword argments (Ruby2.0 spec)

Nagai asked how keyword arguments and hash-style arguments work in
ruby-2.0, since a lot of hash-style arguments appear in his extension
library ‘Ruby/Tk’. Matz proposed following two solutions.
(a) hash-style argument appearing at the end of argument list is
supported as usual.
(b) hash-style arguments were abolished.

I’d prefer (a), because backward-compatibility is a good thing, and I’d
prefer to change my code as little as possible to make it work on Ruby
2.0.

I’d vote for (a), too. I use this syntax as part of the programmer’s
interface of a simulation language embedded in ruby. So it’s not a just
matter of updating my own code, but of changing the interface that users
see.

Here’s an example of code written in this embedded language:

class C
flow { diff “x’ = 1” } # Runge-Kutta integration
transition State1 => State2, State3 => State4 do
guard “x > 2”
reset :x => 0
end
end

It just doesn’t look the same with

transition State1: State2 do …

or

 reset x: 0

But maybe I’ve relied too much on an incidental aspect of ruby syntax… :frowning:

···

On Thu, Jun 03, 2004 at 12:00:51AM +0900, Takaaki Tateishi wrote:

5

Hi,

At Thu, 3 Jun 2004 02:33:44 +0900,
Paul Brannan wrote in [ruby-talk:102177]:

But how would (a) work? It seems like it would make the following
ambiguous:

def foo(foo, bar=2)
end

foo(:foo => 14, :bar => 92)

(is this calling foo with a hash and leaving bar with default argument,
or is it calling foo with foo equal to 14 and bar equal to 92?)

The former. The latter syntax will be

foo(foo: 14, bar: 92)

···

–
Nobu Nakada

6

Paul Brannan wrote:

[ruby-dev:23572] keyword argments (Ruby2.0 spec)

Nagai asked how keyword arguments and hash-style arguments work in
ruby-2.0, since a lot of hash-style arguments appear in his extension
library 'Ruby/Tk'. Matz proposed following two solutions.
   (a) hash-style argument appearing at the end of argument list is
       supported as usual.
   (b) hash-style arguments were abolished.

I'd prefer (a), because backward-compatibility is a good thing, and I'd
prefer to change my code as little as possible to make it work on Ruby
2.0.

But I suspect there will be lots of changes needed for Ruby 1.x source to work with Ruby2. For instance, as I understand, the syntax for hash literal will become:

  {'foo': 1, 'bar': 2}

where in Ruby1.x it's:

  {'foo', 1, 'bar', 2}
  {'foo' => 1, 'bar' => 2}

I suspect Ruby2 will forbid the latter?

I use hash almost everywhere, so...

···

--
dave

7

Lovely!

So that means

foo(bar: 1, :bar => 2)

will pass two distinct arguments:

  1. the integer 1 in keyword argument “bar”, and

  2. the hash {:bar => 2} ?

I like it, even though it is a little inconsistent with

irb(main):001:0> {bar: 1} == {:bar => 1}
=> true
irb(main):002:0> RUBY_VERSION
=> “1.9.0”

···

nobu.nokada@softhome.net wrote:

Hi,

At Thu, 3 Jun 2004 02:33:44 +0900,
Paul Brannan wrote in [ruby-talk:102177]:

But how would (a) work? It seems like it would make the following
ambiguous:

def foo(foo, bar=2)
end

foo(:foo => 14, :bar => 92)

(is this calling foo with a hash and leaving bar with default argument,
or is it calling foo with foo equal to 14 and bar equal to 92?)

The former. The latter syntax will be

foo(foo: 14, bar: 92)

8

sorry for asking again, but I went ignored the first time, this is the
last time I try:
Why we make a distinction beetween positional/default args and named
args ?
Being able to threat them equally would be much more useful I believe,
cause it would allow smatrte usage of many of the existing libraries
(say, all the GUI code)

···

il Thu, 3 Jun 2004 09:24:32 +0900, nobu.nokada@softhome.net ha scritto::

Hi,

At Thu, 3 Jun 2004 02:33:44 +0900,
Paul Brannan wrote in [ruby-talk:102177]:

But how would (a) work? It seems like it would make the following
ambiguous:

def foo(foo, bar=2)
end

foo(:foo => 14, :bar => 92)

(is this calling foo with a hash and leaving bar with default argument,
or is it calling foo with foo equal to 14 and bar equal to 92?)

The former. The latter syntax will be

foo(foo: 14, bar: 92)

9

No, both will work.

{a: 1} in Ruby >= 1.9 is just a short form for {:a => 1} or at least
that's how I understood it.

Regards,

  Michael

···

On Thu, Jun 03, 2004 at 07:07:17PM +0900, David Garamond wrote:

Paul Brannan wrote:
>>[ruby-dev:23572] keyword argments (Ruby2.0 spec)
>>
>> Nagai asked how keyword arguments and hash-style arguments work in
>> ruby-2.0, since a lot of hash-style arguments appear in his extension
>> library 'Ruby/Tk'. Matz proposed following two solutions.
>> (a) hash-style argument appearing at the end of argument list is
>> supported as usual.
>> (b) hash-style arguments were abolished.
>
>
>I'd prefer (a), because backward-compatibility is a good thing, and I'd
>prefer to change my code as little as possible to make it work on Ruby
>2.0.

But I suspect there will be lots of changes needed for Ruby 1.x source
to work with Ruby2. For instance, as I understand, the syntax for hash
literal will become:

{'foo': 1, 'bar': 2}

where in Ruby1.x it's:

{'foo', 1, 'bar', 2}
{'foo' => 1, 'bar' => 2}

I suspect Ruby2 will forbid the latter?

10

the old syntax should remain. But in addition you get:

foo: bar
that would mean:
:foo => bar

···

il Thu, 3 Jun 2004 19:07:17 +0900, David Garamond <lists@zara.6.isreserved.com> ha scritto::

But I suspect there will be lots of changes needed for Ruby 1.x source
to work with Ruby2. For instance, as I understand, the syntax for hash
literal will become:

{'foo': 1, 'bar': 2}

where in Ruby1.x it's:

{'foo', 1, 'bar', 2}
{'foo' => 1, 'bar' => 2}

I suspect Ruby2 will forbid the latter?

11

Hi,

At Thu, 3 Jun 2004 09:40:58 +0900,
Joel VanderWerf wrote in [ruby-talk:102226]:

So that means

foo(bar: 1, :bar => 2)

will pass two distinct arguments:

  1. the integer 1 in keyword argument “bar”, and

  2. the hash {:bar => 2} ?

I’m not sure whether it will be allowed, non-keyword arguments
after keyword arguments.

···

–
Nobu Nakada

12

Hi,

At Thu, 3 Jun 2004 19:09:59 +0900,
gabriele renzi wrote in [ruby-talk:102251]:

>At Thu, 3 Jun 2004 02:33:44 +0900,
>Paul Brannan wrote in [ruby-talk:102177]:
>> But how would (a) work? It seems like it would make the following
>> ambiguous:
>>
>> def foo(foo, bar=2)
>> end
>>
>> foo(:foo => 14, :bar => 92)
>>
>> (is this calling foo with a hash and leaving bar with default argument,
>> or is it calling foo with foo equal to 14 and bar equal to 92?)
>
>The former. The latter syntax will be
>
> foo(foo: 14, bar: 92)

Why we make a distinction beetween positional/default args and named
args ?

This is not that distinction, but between hash literal and
named args.

···

--
Nobu Nakada