As far as I understand it the current spec is to have "using" be available only to main and only apply in the file scope. IMHO this makes the feature nearly useless.
If you explore the topic, there are solid reasons from performance, to vm ports, to readability for why refinements have been curtailed. I'm quite happy with this. The original refinement support would have held ruby back, even if it had its uses.
It's amazing that considering Ruby's philosphy we didn't have named arguments until now. I think this was a case where the idiom of using hashes as named arguments working well enough that the core team didn't feel the need to address it earlier, still proper keyword arguments are going to be great.
I thought Matz was going to drop refinements for 2.0 for now?
> the idiom of using hashes as named arguments working well enough that the core team didn't feel the need to address it earlier
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)
In a statically-typed language, the compiler would know that {value: 42} was created once and never reused, and since the value is a literal, the :value key could simply have been plugged directly into the value variable. Also, the lookup of :path is completely unnecessary in this case.
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
Of course, this decreases allocation while adding complexity.
So yes, I absolutely agree that it's amazing. :-) I think the core team should have considered it earlier.
Some might argue that if you're using Ruby and are worried about the cost of hashes, you might want to consider switching to another language. There are other concerns about "expensiveness" in Ruby that far outweigh usage of hashes.
That seems like a false dichotomy to me. Clearly I can worry about the cost of hashes and be using Ruby productively and performantly. (Unless I were writing programs whose performance was really dependent on hash performance; I don't use Ruby in those cases.)
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.
As a Python dev keyword arguments are among my top language features. Kinda surprised that Ruby doesn't have them yet.
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.)
For the dev environment you can use rbenv or rvm and your favorite text editor. https://www.ruby-toolbox.com/ is a good source for 3rd party libs. About idiomatic style I have learned from reading code from some popular gems.
Keyword arguments are not that important. They're a very nice feature but most of the benefits it will bring could be emulated easily using hashes (not telling you anything you didn't already know I guess).
It's nice to see that we won't have to rely on smart hacks though and that real keyword arguments are now available, but it's nowhere near earth-shattering.
As for refinements, it's theoretically a very nice feature, but it seems that the details are still hazy and the green-ness of the feature raises more eyebrows than it solves problems.
"DTrace can be used to get a global overview of a running system, such as the amount of memory, CPU time, filesystem and network resources used by the active processes. It can also provide much more fine-grained information, such as a log of the arguments with which a specific function is being called, or a list of the processes accessing a specific file."
For anyone else that wasn't aware what Dtrace does.
OT: does anyone else notice that the Japanese text doesn't render correctly (in Chrome and Firefox on Linux & Windows) unless they manually change the encoding to EUC-JP? Why doesn't it work with Unicode, for the Ruby ML, of all things?
The server does not send the charset in the response headers, and the document that is generated does not contain a charset like this:
<meta charset="utf-8">
Either of those two options should fix the page, but I assume Japanese browsers have different default charset than ours since no one has fixed it yet.
Does anyone know what ever happened with Kiji, it seems a generational GC for Ruby has already been coded twice, yet in 2.0 it seems the only big change is the CoW friendly GC
I don't know the specific characteristics of Kiji, but I know that it is not a real generational GC. A generational GC that doesn't break every C extension is impossible because Ruby passes around direct pointers, so Ruby objects can't be moved in memory.
That being said, I'm not a language or VM guy, so take what I say with a grain of salt.
As far as I understand it the current spec is to have "using" be available only to main and only apply in the file scope. IMHO this makes the feature nearly useless.