Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > ruby-dev summary 23566-23622

Reply
Thread Tools

ruby-dev summary 23566-23622

 
 
Takaaki Tateishi
Guest
Posts: n/a
 
      06-02-2004
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 <(E-Mail Removed)>


 
Reply With Quote
 
 
 
 
Paul Brannan
Guest
Posts: n/a
 
      06-02-2004
On Thu, Jun 03, 2004 at 12:00:51AM +0900, Takaaki Tateishi 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 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



 
Reply With Quote
 
 
 
 
Joel VanderWerf
Guest
Posts: n/a
 
      06-02-2004
Paul Brannan wrote:
> On Thu, Jun 03, 2004 at 12:00:51AM +0900, Takaaki Tateishi 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 => 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...


 
Reply With Quote
 
Hidetoshi NAGAI
Guest
Posts: n/a
 
      06-02-2004
Hi,

From: "Takaaki Tateishi" <(E-Mail Removed)>
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].
--
Hidetoshi NAGAI ((E-Mail Removed))


 
Reply With Quote
 
nobu.nokada@softhome.net
Guest
Posts: n/a
 
      06-03-2004
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


 
Reply With Quote
 
Joel VanderWerf
Guest
Posts: n/a
 
      06-03-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) 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)


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"


 
Reply With Quote
 
nobu.nokada@softhome.net
Guest
Posts: n/a
 
      06-03-2004
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


 
Reply With Quote
 
gabriele renzi
Guest
Posts: n/a
 
      06-03-2004
il Thu, 3 Jun 2004 09:24:32 +0900, (E-Mail Removed) 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)


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)
 
Reply With Quote
 
David Garamond
Guest
Posts: n/a
 
      06-03-2004
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


 
Reply With Quote
 
Michael Neumann
Guest
Posts: n/a
 
      06-03-2004
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?


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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Thunderbird--takes so long to build summary file GLC Firefox 1 11-15-2005 05:10 AM
how to force Mozilla 1.7 to rebuild all email index/summary files? Marvin Glenn, ASNN Firefox 1 06-23-2004 11:08 PM
Inbox summary file constantly rebuilt Leif K-Brooks Firefox 3 05-18-2004 04:26 AM
Comments requested: brief summary of Perl Adam Barr Perl 1 02-24-2004 06:03 PM
validation summary doesnt display when there's client-side validation Libs ASP .Net 0 06-25-2003 03:05 PM



Advertisments