Ruby 1.9: What to Expect by Sam Ruby @ OSCON 2008 Slide Deck Adapted S6/S9 (Single-Web Page) Version

Hello,

I’ve created a S6/S9 version of Sam Ruby’s OSCON 2008 slide deck
titled “Ruby 1.9: What to Expect (What’s Changed? What’s New?)” that
offers a single-web page version that in addition to offering a
full-screen slide show is easy-to-print for offline reading. (S6/S9
Tip: Use the t-key to toggle between outline and slide show view.)

Topics covered in Sam Ruby’s slide show include:

== What’s Changed?

  • Single Character Strings
  • String Index
  • {“a”,“b”} No Longer Supported
  • Array.to_s Now Contains Punctuation
  • Colon No Longer Valid In When Statements
  • Block Variables Now Shadow Local Variables
  • Hash.index Deprecated
  • Fixnum.to_sym Now Gone
  • Hash Keys Now Unordered
  • Stricter Unicode Regular Expressions
  • tr and Regexp Now Understand Unicode
  • pack and unpack
  • BasicObject More Brutal Than BlankSlate
  • Delegation Changes
  • Use of $KCODE Produces Warnings
  • instance_methods Now an Array of Symbols
  • Source File Encoding

== What’s New?

  • Alternate Syntax for Symbol as Hash Keys
  • Block Local Variables
  • Inject Methods
  • to_enum
  • No block? Enum!
  • Lambda Shorthand
  • Complex Numbers
  • Decimal Is Still Not The Default
  • Regex “Properties”
  • Splat in Middle
  • Fibers
  • Break Values
  • “Nested” Methods

More @ http://slideshow.rubyforge.org/ruby19.html

Cheers.

El Martes, 12 de Agosto de 2008, Gerald B.
escribió:> * Block Variables Now Shadow Local Variables

What does it mean? For example, in Ruby 1.8 and 1.9 the following code
returns
the same:


kk=123;
puts “KK out of block = #{kk}”;
1.upto(3) { puts “KK in block = #{kk}”; kk=999 };
puts “KK out of block = #{kk}”

KK out of block = 123
KK in block = 123
KK in block = 999
KK in block = 999
KK out of block = 999

On Tue, Aug 12, 2008 at 1:36 PM, Iñaki Baz C. [email protected] wrote:


KK out of block = 123
KK in block = 123
KK in block = 999
KK in block = 999
KK out of block = 999

$ irb-1.8

a = 1
=> 1
[2].each { |a| }
=> [2]
a
=> 2

$ irb-1.9

a = 1
=> 1
[2].each { |a| }
=> [2]
a
=> 1

So the block arg ‘a’ no longer clobbers the local var ‘a’.

jeremy

El Martes, 12 de Agosto de 2008, Iñaki Baz C.
escribió:

the result is the same (but true, if I run your code in 1.8 and 1.9 result
is different, but I don’t understand which is the difference between your
code and mine).

Maybe the difference occurs when the variable is passed to the block as
parameter ( {|a| …} ) ?

El Martes, 12 de Agosto de 2008, Jeremy K.
escribió:> > puts “KK out of block = #{kk}”

a = 1

a

=> 1

So the block arg ‘a’ no longer clobbers the local var ‘a’.

jeremy

No sure if I understand you. Please lok at this code:

~# irb1.8
irb(main):001:0> a=1
1
irb(main):002:0> [2].each { a=3 }
[2]
irb(main):003:0> a
3

~$ irb1.9
irb(main):001:0> a=1
1
irb(main):002:0> [2].each { a=3 }
[2]
irb(main):003:0> a
3

the result is the same (but true, if I run your code in 1.8 and 1.9
result is
different, but I don’t understand which is the difference between your
code
and mine).

Thanks a lot for so good explanation.

2008/8/12 Gerald B. [email protected]:

Hello,

I’ve created a S6/S9 version of Sam Ruby’s OSCON 2008 slide deck
titled “Ruby 1.9: What to Expect (What’s Changed? What’s New?)” that
offers a single-web page version that in addition to offering a
full-screen slide show is easy-to-print for offline reading. (S6/S9
Tip: Use the t-key to toggle between outline and slide show view.)

Thanks!

It says “Hash Keys Now Unordered” and shows an example where
Ruby 1.8 happens to print the keys in alphabetic order.

Hash keys in 1.8 are not ordered in any documented way. In fact,
the headline should say “Hash Keys Now (Insertion) Ordered”.

Stefan

Hi –

On Wed, 13 Aug 2008, Iñaki Baz C. wrote:

El Martes, 12 de Agosto de 2008, Iñaki Baz C. escribió:

the result is the same (but true, if I run your code in 1.8 and 1.9 result
is different, but I don’t understand which is the difference between your
code and mine).

Maybe the difference occurs when the variable is passed to the block as
parameter ( {|a| …} ) ?

Yes. If it’s a block parameter, it will not clobber the outer
variable. If you just use a variable (non-parameter) in the block,
then it is the same as the outer variable. (That’s how blocks work as
closures.)

If you want to use a non-parameter inside a block and have it not
clobber an outside variable, you can declare it as a local variable by
putting it after a semi-colon in the parameter list:

{|x,y,z;a| a = 1 } # a is not bound to any block args but is
# local to the block

David

El Martes, 12 de Agosto de 2008, David A. Black escribió:

If you want to use a non-parameter inside a block and have it not
clobber an outside variable, you can declare it as a local variable by
putting it after a semi-colon in the parameter list:

  {|x,y,z;a| a = 1 }   # a is not bound to any block args but is
             # local to the block

Could I use that to avoid the problem if I do this:

Thread.new(request) { |request| … }

This is a big problem since the “request” into the block points to the
request
outside, so each thread share it (dangerous). This is why I use:

Thread.new(request) { |req| … }

Could I use this?
Thread.new(request) { |;request| … }

Thanks.

Hi –

On Thu, 14 Aug 2008, Iñaki Baz C. wrote:

Thread.new(request) { |request| … }

This is a big problem since the “request” into the block points to the request
outside, so each thread share it (dangerous). This is why I use:

Thread.new(request) { |req| … }

Could I use this?
Thread.new(request) { |;request| … }

No, because you then have no block parameter to which to bind the
thread object. Variables listed after the semi-colon are available as
local variables in the block, but do not participate in the argument
bindings.

David

On Thu, 2008-08-14 at 03:33 +0900, Iñaki Baz C. wrote:

Thread.new(request) { |;request| … }
In 1.9, you don’t need to. Block parameters shadow local variables,
such that this works fine:

Thread.new(request) { |request| … }

In 1.9, ‘request’ inside and outside the block are different variables.

(I’m still not entirely sure I’d recommend calling them the same thing,
for readability’s sake, but you can do it now…)

-mental

Thanks.

El Miércoles, 13 de Agosto de 2008, MenTaLguY escribió:

Could I use this?
Thread.new(request) { |;request| … }

In 1.9, you don’t need to. Block parameters shadow local variables,
such that this works fine:

Yeah, I know, that is why I asked a solution for 1.8 :slight_smile:

Thread.new(request) { |request| … }

In 1.9, ‘request’ inside and outside the block are different variables.

(I’m still not entirely sure I’d recommend calling them the same thing,
for readability’s sake, but you can do it now…)

Why?

Thanks.

Hello,

There’s a couple errors or oddities in the slides.

  • Hash Keys Now Unordered
  • Inject Methods
  • Decimal Is Still Not The Default
  • Break Values
  • “Nested” Methods

Please note that I’ve just created a single-web-page S6/S9 rendition
of the original slide deck from Sam Ruby’s talk. If you want to get
the errors and oddities fixed or addressed I recommend telling Sam
Ruby e.g. on his blog @
http://intertwingly.net/blog/2008/07/24/Ruby-1-9-What-to-Expect

Cheers.

There’s a couple errors or oddities in the slides.

Gerald B. wrote:

  • Hash Keys Now Unordered

As someone else noted, hash keys have never been ordered in 1.8.6 or
earlier. The example shown is in alphabetical order purely by chance.
1.9 adds insertion ordering. JRuby also has insertion-ordered hashes
already.

  • Inject Methods

This is really a larger change, the addition of to_proc to Symbol
similar to what ActiveSupport provides. It’s not specific to inject.

  • Decimal Is Still Not The Default

I doubt Decimal will ever be the default, no matter how people wish it.

  • Break Values

This is no different than Ruby 1.8.x.

  • “Nested” Methods

This is nothing new; a method defined in another method just defines on
the same class, as normal. They’re not really “nested”.

There’s also a “Real threading” slide that confused me. Ruby 1.9 does
use real kernel threads, but they don’t run in parallel.

  • Charlie