ruby-dev summary 24171-24235

[Minero Aoki]

Hi all,

This is a summary of ruby-dev ML in these days.

[ruby-dev:24183] CGI::Session problem again

(posted by Shugo Maeda)

Gotou Yuuzou pointed out that the previous cgi/session fix is insufficient
because local users can estimate process IDs and the system time.
He wrote an exploit code and it can crack CGI session in a minute.

This local exploit has NOT been fixed yet.

[ruby-dev:24203] $~ alternative

Shugo Maeda proposed a new multiple assignment scheme to provide an
alternative of $~ variable. His proposal is similar to the one of
Common Lisp:

a = 1, 2, 3
p a #=> 1

*a = 1, 2, 3
p a #=> [1, 2, 3]

This rule allows to let methods return additional values without
breaking backward compatibility.

idx = "foo bar".index(/oo/) # compatible with current code
idx, m = "foo bar".index(/oo/) # m = $~

"foo bar".gsub(/oo/) do |str| # compatible with current code
....
end
"foo bar".gsub(/oo/) do |str, m| # m = $~
....
end

On the other hand, this scheme breaks codes which use
`auto composite' feature of multiple assignment:

h = {1=>3, 2=>9, 3=>27}
h.each do |pair|
p pair #=> [1,3] now, but 1 by this proposal
end

[ruby-dev:24231] system("")

TANAKA Akira pointed out that system("") produces error while perl
gracefully ignores it.

This issue is still open.

[ruby-dev:24234] ?/! suffix for setter methods

NOWAKE proposed to allowing ?/! suffix for setter methods (xxx!=).

This issue is still open.

-- Minero Aoki

ruby-dev summary index:
http://i.loveruby.net/en/ruby-dev-summary.html

 

[T. Onoma]

On the other hand, this scheme breaks codes which use
  `auto composite' feature of multiple assignment:

    h = {1=>3, 2=>9, 3=>27}
    h.each do |pair|
      p pair     #=> [1,3] now, but 1 by this proposal
    end

that seems bad.

 

[Minero Aoki]

In mail "Re: ruby-dev summary 24171-24235"

On the other hand, this scheme breaks codes which use
  `auto composite' feature of multiple assignment:

    h = {1=>3, 2=>9, 3=>27}
    h.each do |pair|
      p pair     #=> [1,3] now, but 1 by this proposal
    end

that seems bad.

I forgot to note that his proposal is for *Ruby 2*.


Regards,
Minero Aoki

 

[Brian Schroeder]

[ruby-dev:24234] ?/! suffix for setter methods

NOWAKE proposed to allowing ?/! suffix for setter methods (xxx!=).

This issue is still open.

What would be the meaning of xxx!='something'. I'd read it
"xxx is not equal to 'something'"?

regards,

Brian

 

[Kristof Bastiaensen]

Hi,

[ruby-dev:24203] $~ alternative

Shugo Maeda proposed a new multiple assignment scheme to provide an
alternative of $~ variable. His proposal is similar to the one of
Common Lisp:

a = 1, 2, 3
p a #=> 1

*a = 1, 2, 3
p a #=> [1, 2, 3]

This rule allows to let methods return additional values without
breaking backward compatibility.

idx = "foo bar".index(/oo/) # compatible with current code idx, m
= "foo bar".index(/oo/) # m = $~

"foo bar".gsub(/oo/) do |str| # compatible with current code
....
end
"foo bar".gsub(/oo/) do |str, m| # m = $~
....
end

On the other hand, this scheme breaks codes which use `auto composite'
feature of multiple assignment:

h = {1=>3, 2=>9, 3=>27}
h.each do |pair|
p pair #=> [1,3] now, but 1 by this proposal
end

Interesting.
A new multiple assignment scheme will break old code anyway.
In this case you could write "h.each do |*pair|" instead.

A bigger problem would be with the following:
[[1, 3], [2, 9], [3, 27]].each do |arg1, arg2|
p arg1.inspect #=> [1, 3]
p arg2.inspect #=> nil
end

An idea would be to enable pattern matching of arrays inside
argument lists and l-values (à la ML or prolog):

[[1, 3], [2, 9], [3, 27]].each do |[arg1, arg2]|
p arg1.inspect #=> 1
p arg2.inspect #=> 2
end

Regards, KB

 

[gabriele renzi]

Minero Aoki ha scritto:

[ruby-dev:24203] $~ alternative

Shugo Maeda proposed a new multiple assignment scheme to provide an
alternative of $~ variable. His proposal is similar to the one of
Common Lisp:

I don't understand why we need this. Can't we just force users to write:

idx, = "foo bar".index(/oo/)
idx, m = "foo bar".index(/oo/)

Also, what's wrong with Regexp.last_match ?

Note that I think a stricter unpacking may be a good thing, anyway..

 

[Paul Brannan]

[ruby-dev:24231] system("")

TANAKA Akira pointed out that system("") produces error while perl
gracefully ignores it.

s/gracefully //

Paul

 

[Ara.T.Howard]

[ruby-dev:24231] system("")

TANAKA Akira pointed out that system("") produces error while perl
gracefully ignores it.

s/gracefully //

Paul

for me (in ruby) it simply produces false - isn't that graceful?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Ben Giddings]

idx = "foo bar".index(/oo/) # compatible with current code
idx, m = "foo bar".index(/oo/) # m = $~

"foo bar".gsub(/oo/) do |str| # compatible with current code
....
end
"foo bar".gsub(/oo/) do |str, m| # m = $~
....
end

On the other hand, this scheme breaks codes which use
`auto composite' feature of multiple assignment:

h = {1=>3, 2=>9, 3=>27}
h.each do |pair|
p pair #=> [1,3] now, but 1 by this proposal
end

To me, this isn't a big loss. It improves readability /
understandability.

h = {1=>3, 2=>9, 3=>27}

h.each do |a,b|
p a
end

h.each do |a|
p a
end

At a glance, I'd expect both of those methods to do the same thing. I
think that's the more natural behaviour. An additional benefit is that
with this mechanism, 'yield' can pass much more information, in
expected order of usefulness, and you can add parameters if you wish.

For example

if internally Array#each used a "yield element,index,num_left" you
could do:


arr = ["cat", "dog", "bat", "log"]
arr.each do |e|
print "#{e}, "
end
=> cat, dog, bat, log,

arr.each do |e, i, remain|
print e
print "," unless 0 == remain
end
=> cat, dog, bat, log

If I wanted every parameter that 'yield' passes, I'd expect to have to
do

h.each do |*a|
p a
end

I like Kristof Bastiaensen's idea of pattern matching

[[1, 3], [2, 9], [3, 27]].each do |[arg1, arg2]|
p arg1.inspect #=> 1
p arg2.inspect #=> 2
end

But I'm not sure how radical a change that would be to the language, or
how easy it would be to do.

I also wonder if there's some way of integrating the named parameters
into this.


arr = ["cat", "dog", "bat", "log"]
arr.each do |index: i, element: e|
print "#{e}, "
end

I really like named parameters, because they further insulate you from
changes, and allow people writing libraries to keep adding features
without worrying about breaking backwards compatibility.

Just a thought,

Ben

 

[nobu.nokada]

Hi,

At Thu, 9 Sep 2004 00:45:06 +0900,

[ruby-dev:24231] system("")

TANAKA Akira pointed out that system("") produces error while perl
gracefully ignores it.

s/gracefully //

Paul

for me (in ruby) it simply produces false - isn't that graceful?

In recent 1.9, an exception will raise when the command won't
be found. See the thread from [ruby-talk:104856].

 

[George Ogata]

I like Kristof Bastiaensen's idea of pattern matching

[[1, 3], [2, 9], [3, 27]].each do |[arg1, arg2]|
p arg1.inspect #=> 1
p arg2.inspect #=> 2
end

But I'm not sure how radical a change that would be to the language, or
how easy it would be to do.

If all you want is pattern matching when receiving Arrays, it's
already there -- just use parens instead of brackets:

irb(main):001:0> [[[1, 2], 3], [[4, 5], 6]].each do |((a, b), c)|
irb(main):002:1* p a
irb(main):003:1> p b
irb(main):004:1> p c
irb(main):005:1> end
1
2
3
4
5
6
=> [[[1, 2], 3], [[4, 5], 6]]

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 24171-24235"

|Also, what's wrong with Regexp.last_match ?

Because that is a hidden global variable.

matz.

 

[Kristof Bastiaensen]

I like Kristof Bastiaensen's idea of pattern matching

[[1, 3], [2, 9], [3, 27]].each do |[arg1, arg2]|
p arg1.inspect #=> 1
p arg2.inspect #=> 2
end

But I'm not sure how radical a change that would be to the language, or
how easy it would be to do.

If all you want is pattern matching when receiving Arrays, it's already
there -- just use parens instead of brackets:

irb(main):001:0> [[[1, 2], 3], [[4, 5], 6]].each do |((a, b), c)|
irb(main):002:1* p a
irb(main):003:1> p b
irb(main):004:1> p c
irb(main):005:1> end
1
2
3
4
5
6
=> [[[1, 2], 3], [[4, 5], 6]]

Yes, but with the proposed scheme for multiple values, this will not
be possible anymore:

(a, b) = [1, 2] # a == [1, 2], b == nil

Unless you would say that explicit grouping (with parenthese) splits
arrays, and implicit (without parentheses) gets multiple values. That's
an interesting idea!

KB