[#24105] [Bug #1711] Marshal Failing to Round-Trip Certain Recurisve Data Structures — Run Paint Run Run <redmine@...>

Bug #1711: Marshal Failing to Round-Trip Certain Recurisve Data Structures

9 messages 2009/07/01

[#24116] [Bug #1715] Numeric#arg for NaN is Inconsistent Across Versions — Run Paint Run Run <redmine@...>

Bug #1715: Numeric#arg for NaN is Inconsistent Across Versions

10 messages 2009/07/02

[#24240] [Bug #1755] IO#reopen Doesn't Fully Associate with Given Stream on 1.9; Ignores pos on 1.8 — Run Paint Run Run <redmine@...>

Bug #1755: IO#reopen Doesn't Fully Associate with Given Stream on 1.9; Ignores pos on 1.8

8 messages 2009/07/09

[#24321] [Bug #1773] Gem path doesn't honor user gem? — Lin Jen-Shin <redmine@...>

Bug #1773: Gem path doesn't honor user gem?

12 messages 2009/07/14

[#24390] [Feature #1784] More encoding (Big5 series) support? — Lin Jen-Shin <redmine@...>

Feature #1784: More encoding (Big5 series) support?

12 messages 2009/07/16

[#24467] Re: [ruby-cvs:31226] Ruby:r24008 (ruby_1_8_6): Removed private on to_date and to_datetime. — Urabe Shyouhei <shyouhei@...>

Hello.

10 messages 2009/07/21

[#24472] [Feature #1800] rubygems can replace system executable files — Kazuhiro NISHIYAMA <redmine@...>

Feature #1800: rubygems can replace system executable files

13 messages 2009/07/21

[#24530] [Feature #1811] Default BasicSocket.do_not_reverse_lookup to true — Roger Pack <redmine@...>

Feature #1811: Default BasicSocket.do_not_reverse_lookup to true

9 messages 2009/07/23

[#24624] [Bug #1844] Immediates Should Not Respond to :dup — Run Paint Run Run <redmine@...>

Bug #1844: Immediates Should Not Respond to :dup

15 messages 2009/07/30

[ruby-core:24421] lvar_propagate

From: Yehuda Katz <wycats@...>
Date: 2009-07-18 06:17:36 UTC
List: ruby-core #24421
Matz,
Very good keynote today. I enjoyed looking at some of the new features you
are playing around with. I was very existed about lvar_propagate, and am
hoping I can convince you to give it another chance :)

Here's why: In my ideal world, blocks behave transparently to the end user.
There would be no difference between:

if foo == bar
  # stuff
end

and

Util.if(foo == bar) do
  # stuff
end

For the most part, this works, and is why Ruby can have a for/in syntax that
appears to many new users as a special language construct when it in fact
only wraps a block. This ability is key to Ruby's power over other
languages, because frameworks and other utility libraries can add new
"language features" easily. Python, in contrast, is specifically *against*
this sort of power.

Adding lvar_propagate (along with restoring 1.8 constant lookup behavior)
would remove the one remaining roadblock to having blocks that are true
stand-ins for language features. In the context of current Ruby, I can see
why the functionality seems ugly, but consider what you have to do in Ruby
1.8:

x = nil
something do
  x = 42
end
# access x

I think this is *uglier* than:

something do
  x = 42
end
# access x

In particular, I think the fact that this functionality would allow you to
implement method versions of Ruby language features is a compelling reason
to do it. What's most interesting to me is that it doesn't appear to have
any obvious user-facing drawbacks. Since the functionality is not currently
available, the only potential breakage would be:

something do
  x = 41
end
# code that specifically expects "x" to raise an exception

which seems like enough of an edge-case as to be considered insignificant.

-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

In This Thread

Prev Next