I thought Matz was going to drop refinements for 2.0 for now?
Hashes are hideously expensive, though: For every method call, an entire object has to be populated and hashed. The hashing is fast enough for symbol keys, sure, but it's still a whole data structure that must be allocated and later garbage collected.
Since Ruby hashes are mutable and there is no way to track the mutation across methods, the compiler cannot optimize single-use hash literals into a constant. (When all keys and literals are values it could pre-allocate a structure that is copy-on-write internally, but to my knowledge it doesn't do this.) For example, this is a typical pattern:
def generate_useless_stuff(options = {})
path = options[:path] || @default_path
value = options[:value]
File.open(path, "w") { |f| f << ("*" * value) }
end
generate_useless_stuff(value: 42)
Often all the options are optional, and even then a call to generate_useless_stuff() will generate an empty hash. This is why I tend to write methods, when performance-sensitive, as:
def generate_useless_stuff(options = nil)
path = options[:path] || @default_path if options
value = options[:value] if options
File.open(path, "w") { |f| f << ("*" * value) }
end
So yes, I absolutely agree that it's amazing. :-) I think the core team should have considered it earlier.
Anyway, everything adds up. Even for webapps in Rails or Sinatra, the sheer number of method calls in a single template may contribute significant overhead to the rendering of a page. Which means that shaving a few microseconds off a method call may in fact boost performance measurably. I am hoping this will be the case with named arguments.
On a slightly off-topic note, what's the best way to dive into Ruby coming from (strong) Python background? I bet the syntax wouldn't take more than a weekend to get used to but I'm more interested in the less trivial stuff (semantics, idiomatic style, dev environment, 3rd party lib ecosystem etc.)