Comment by grey-area | Hacker News Reader

Comment by grey-area | Hacker News Reader

There are some nice features here:

Keyword arguments, which give flexibility to API design

This looks good to replace all those options hashes in rails for example, though I wish they'd made it an all or nothing thing, apparently you can still do this:

    def foo(x, str: "foo", num: 424242)

i.e. use some named and some unnamed in the same method which looks ugly.

Module#prepend, which is a new way to extend a class

Compared to something like Go, I do worry the Ruby inheritance picture is becoming overly complex, but I guess there must have been some use case for this - anyone know where it is going to be used?

__dir__, which returns the dirname of the file currently being executed

This is a great little enhancement which means I can replace File.dirname(__FILE__) from the start of a lot of utility scripts. Would love to have seen more little improvements like this.

The UTF-8 default encoding, which make many magic comments omissible

At last! This should have been in 1.9.

Performance improvements

While these are incremental, it's nice to see more improvements - thanks Ruby team!

Onigmo, which is a new regexp engine (a fork of Oniguruma)

Not sure what this changes from Oniguruma.

Refinements

Refinements seems to be the headline feature for a lot of people, but I have two hesitations about it: it's encouraging a practice which has come to be seen as one of the most dangerous parts of Ruby - monkey patching, and the process of deciding its inclusion seems to have brought about a few schisms with the community developing alternative Ruby implementations because of performance implications, and raised wider issues about the Ruby design process:

http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-d...

There is the argument of course that it's attempting to limit monkey patching and therefore limit the damage caused, but should it be encouraged at all? It'd be interesting to hear more on what happened here from anyone has been following this closely.

I like the idiom of mixed named and not named parameters in Ruby. You don't really need names for implied, required parameters. Consider:

    protagonist.throw(potato, :force => 3, :at => zombie)

In this case a call to :throw without an object to throw is nonsense. Throw is a transitive verb, and the parameter is implied. On a throw method, the parameter is obviously the thing being throw'ed.

On the other hand, the optional parameters are totally obscure, and need to be named.

Similarly:

    justice.join_in_matrimony(jay, bob)

The two unnamed parameters here are the things being join_in_matrimony'ed.

In other words: unnamed parameters are for direct objects, named parameters are for adjectives and prepositions.

Although arguably the Rubyish thing to do with prepositions is chain them:

    protagonist.throw(potato, force: 3).at(zombie)

yes I see your point, it just feels inconsistent somehow, as named parameters are nicely self-documenting, could be used to generate docs etc, but that's probably just a foolish consistency. In your example you could be cute and have something like:

     protagonist.throw(a: => potato, :at => zombie, :force => 3)

which would be just as nice. But I'm sure there are places where this will be useful/necessary, in your chained example with single args it feels forced to have to name them.

Module#prepend doesn't look too bad from me from a complexity perspective - inheritance in Ruby boils down to two parallel trees: One of the inheritance chains, and one of the method lookups. Really we're dealing with a single tree of "actual" inheritance, with some of them being "hidden" in some contexts. It gets a bit complex if you want to do meta-programming or do something that depends on the inheritance hierarchy, but mostly it behaves the way people expect in regular use.

Refinements, on the other hand, looks brain-damaged to me. I see the rationale, but the outcome looks more complicated and error-prone than the situation it is trying to address...

And it looks like the type of thing that will "infect" other code, just like C++ code for a while got infections of throw specifications on member functions, that then got propagated all over the place and cause major pain every time you tried to modify code. Until most people stopped using them much again except in very limited circumstances.

Yes it's not hugely complex, but it does complicate the composition side of code inheritance a little more as you have to think about how a module might be included as well as which modules and which superclasses you have. Contrast this with go which has no inheritance and only simple composition and is vastly simpler to comprehend re the reuse of code due to those limits.

Re refinements I agree and find it worrying that it was added given the widespread objections.

There was a post here a while ago about a language that didn't use 'super' inside subclassed methods, but instead had something used in the parent class method to call the same one in any subclass. I quite liked the idea of that.

Looks like Module#prepend is there to do a similar thing.

A very common use case for Module#prepend is for mixins that want to decorate methods.

For example, say I have a class that can process stuff, and a mixin that attempts to log calls to the #process method:

     class Processor
       def process
         puts "Very important stuff here"
       end
     end

     module Logger
       def process
         puts "Entering process."
         super
         puts "Leaving process."
       end
     end

If you just ``include Logger`` in Processor it won't work: Processor#process is looked up before Logger#process. However, if you use Module#prepend, the ancestry chain will change and calls to Process#process will be decorated as expected.

Thanks for the example.

Speaking of the video you posted, go to 8:43.

"I know someone who is working on a Ruby implementation and making very good strides and is not talking about it publicly at all--and I think you'll be surprised when you find out about it."

Is Brian Ford talking about Topaz [1]?

[1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/

Probably, yes. If you hung out in #rubinius over the last year, you'd see Alex Gaynor hanging out.

Mixing keyword and non-keyword arguments isn't entirely ugly. It is in the "foo" case since "foo" is deliberately meaningless, but when there's one principal argument and the other arguments tweak or override the method's behavior, it's fine.

Reply on news.ycombinator.com