Hacker News Reader

Comment by JohnBooty | Hacker News Reader

According to Matz last year,

"The version number goes up to 2.0 but the changes are rather small. Smaller than the ones we made in 1.9."

http://www.rubyinside.com/ruby-2-0-implementation-work-begin...

Here's a Quora thread with links to a presentation by Matz and a summary by Yehuda Katz: http://www.quora.com/Ruby-programming-language/What-are-the-...

"Language improvements:

- Named arguments.. 1.step(by: 2, to: 10) { ... }

- Selector namespaces (unclear to me whether this differs from refinements as described by Katz)

- Multiple inheritance

Interpreter Improvements:

- Incremental performance improvements over 1.9's VM

- Better compatibility with non-unix environments and small/constrained devices (embeddable)

- Sandboxed VM's (VM per thread)"

Matz's presentation: http://www.youtube.com/watch?feature=player_embedded&v=t...

Yehuda's summary of "refinements": http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-pra...

View on HN

> Named arguments

yes, though it's basically an optional argument hash. AFAIK, you can't do required named arguments without weird hacks, or specifically checking the arguments. For example:

    irb(main):007:0> def foo(bar: bar, baz: Object.new); [bar, baz]; end
    => nil
    irb(main):008:0> foo(bar: 1)
    => [1, #<Object:0x007fcaa40db4e0>]
    irb(main):009:0> foo(baz: 1)
    NameError: undefined local variable or method `bar' for main:Object
    	from (irb):7:in `foo'
    	from (irb):9
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):010:0>

This hack makes the "bar" parameter required, but only because the value is evaluated when the method is called, and you get a NameError (rather than an ArgumentError).

> Selector namepaces

yes, but it's called refinements. You can see how they're used here: https://github.com/ruby/ruby/blob/trunk/test/ruby/test_refin... (sorry for the link to a test, I'm feeling lazy ;-) )

> Multiple inheritance

Sorry, there won't be multiple inheritance.

> Incremental performance improvements over 1.9's VM

yes, ko1 has been working on removing / optimizing bytecodes in the VM.

> Better compatibility with non-unix environments and small/constrained devices (embeddable)

I don't know of any work on this other than mruby, which isn't MRI.

> Sandboxed VM's (VM per thread)

nope. https://bugs.ruby-lang.org/issues/7003

Other stuff:

* DTrace probes

* Better within ruby tracing https://bugs.ruby-lang.org/issues/6895

I run edge ruby against rails daily. The main incompatibilities I've hit in Ruby 2.0 are what methods respond_to? searches (I've blogged about that here: http://tenderlovemaking.com/2012/09/07/protected-methods-and... ), and the `Config` constant has been removed (which is sometimes an issue for C extensions).

EDIT

Just thought of this for the required args:

    irb(main):001:0> def foo(bar: (raise ArgumentError), foo: Object.new); [bar, foo]; end
    => nil
    irb(main):002:0> foo(bar: 1)
    => [1, #<Object:0x007fc65a882f48>]
    irb(main):003:0> foo(foo: 1)
    ArgumentError: ArgumentError
    	from (irb):1:in `foo'
    	from (irb):3
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):004:0>

You could probably define a private method like `required` or some such, like this:

    irb(main):001:0> def required(name); raise ArgumentError, "missing param: %s" % name; end
    => nil
    irb(main):002:0> def foo(bar: required(:bar), foo: Object.new); [bar, foo]; end
    => nil
    irb(main):003:0> foo(bar: 1)
    => [1, #<Object:0x007fcfea143338>]
    irb(main):004:0> foo(foo: 1)
    ArgumentError: missing param: bar
    	from (irb):1:in `required'
    	from (irb):2:in `foo'
    	from (irb):4
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):005:0>

> > Multiple inheritance

> Sorry, there won't be multiple inheritance.

Thank all that is holy in the world.

Amen to that.

C++ pretty much ruined that party for everyone.

So it's syntactic sugar? What a shame. The whole point is having the language handle it so its default behavior is well-known and uniform and not implement umpteenth patterns and validations[0].

[0] e.g assert_valid_keys (raising ArgumentError on a mismatch so it's really only for options={} pattern: http://api.rubyonrails.org/classes/Hash.html#method-i-assert...

Well, it does actually define locals. But, IIRC, it uses the symbol hash parsing productions, so the default values are required. The only way to specify required parameters (without the above hacks) is to do a traditional method definition:

    irb(main):001:0> def foo(bar, baz: Object.new); [bar, baz]; end
    => nil
    irb(main):002:0> foo(1)
    => [1, #<Object:0x007fbc39161ed8>]
    irb(main):003:0> foo(1, baz: 10)
    => [1, 10]
    irb(main):004:0> foo(baz: 10)
    ArgumentError: wrong number of arguments (0 for 1)
    	from (irb):1:in `foo'
    	from (irb):4
    	from /Users/aaron/.local/bin/irb:12:in `<main>'
    irb(main):005:0>

I really like the required(name) solution.

  module RequiredParameter
    refine Kernel
      def required(name)
        raise ArgumentError, ...
      end
      private :required
    end
  end

Can't wait to test this code. :P

another nice vm improvement would be the introduction of unboxed floats in 64 bit architectures (akin to Fixnums)

https://github.com/ruby/ruby/commit/b3b5e626ad69bf22be3228f8...

> * Sandboxed VM's (VM per thread)

This will not make it into Ruby 2.0.0:

https://bugs.ruby-lang.org/issues/7003

Multiple inheritance is the major one for me.. been waiting a long time for this

What does multiple inheritance provide that isn't better achieved through composition/modules?

Agree with you. Didn't we learn from C++ that multiple inheritance is good in theory but in practice a horrible idea? Ruby already lets you be 'magical' in too many ways.

> Didn't we learn from C++ that multiple inheritance is good in theory but in practice a horrible idea?

No, we learned from C++ that C++ multiple inheritance is an atrocity. Python's MI works in a clear and obvious way, similar[0] to how the Ruby inheritance chain is clear and obvious. MI really doesn't fit Ruby though, and IMHO would look too bolted on.

Most of the time the problem is people beating the platform they develop on into submission, instead of embracing it by getting a clear picture of what happens.

[0] As _why said[1], python and ruby are damn close: you can easily get something similar to Ruby's modules and inject them dynamically in the inheritance chain: https://gist.github.com/3951273

[1] https://github.com/whymirror/unholy

It is also available in Eiffel, OCaml and Python.

So there are some good ways to make use of it.

But I agree interfaces/traits is a better way of dealing with multiple inheritance scenario.

Perl (5 & 6) also has multiple inheritance. Current best practise in the Perl community is to avoid using MI and instead make use of roles.

ref: https://metacpan.org/module/Moose::Role | http://en.wikipedia.org/wiki/Perl_6#Roles | http://modernperlbooks.com/mt/2009/05/perl-roles-versus-inhe...

Magic is bad, but multiple inheritance isn't magic; it's clear and obvious, the only potential wrinkle being method resolution order when two superclasses define the same method, which is fine as long as it's consistent and documented.

Almost all of the problems with multiple inheritance in C++ are to do with the static type of an instance, and go away in a language where everything is virtual by default, as in ruby.

Why is that even something worth working on? I find modules work pretty good.

Sometimes you want to express multiple is-a relationships at the same time. In that case, composition is a hack, and multiple inheritance is a better match for the concept.

I prefer having more options how my objects behave than fewer.

But, since Ruby 2.0 does not and will not have multiple inheritance, this is all off-topic.

I'm seeing contradictory information about this. Is multiple inheritance in or out?

Reply on news.ycombinator.com