Hacker News Reader

Comment by chao- | Hacker News Reader

Agreed regarding refinements. I will personally stay away from them until some braver souls find best practices for them in long-term projects. Even then it will take some convincing.

I have been awaiting Ruby keyword arguments for a very long time, but the first time I heard them brought up (relating to 2.0), the person explaining had some qualms with how they were implemented. For the life of me I cannot remember what bothered them, but if that rings a bell for anyone else, please chime in.

View on HN

The complaints I recall about Ruby keyword arguments were on Twitter:

https://twitter.com/brixen/status/281180931950264320

https://twitter.com/garybernhardt/status/281181122736582656.

Not sure if that's what you're thinking of.

@ch0wn: I'm pretty sure that chao- was talking about the implementation of keyword arguments, not refinements.

That was indeed the complaint: That the keyword arguments are actually implemented as a hash underneath. Still useful for loads of reasons, but hopefully will transition to a more optimized implementation one day.

There's a really in-depth article on them that also covers concerns about the implementation: http://blog.headius.com/2012/11/refining-ruby.html

After reading that article, I'm wondering: what's the value of Ruby refinements over dynamically-scoped monkey-patching? Taking the String.camelize example from the article, you could write in Perl:

  sub withCamelize (&) {
      my ($thunk) = @_;
      local *{'String::camelize'} = sub { ... };
      $thunk->()
  }

  sub camelize_and_join {
     my ($str_ary) = @_;
     withCamelize {
        join ', ', map { $_->camelize } @$str_ary
     }
  }

So you can probably already accomplish the same with Ruby's equivalent of 'local' for dynamic scoping.

First, Ruby has no built-in way to accomplish dynamic scoping. Perl is Very Powerful.

Second, refinements apply lexically. Consider a class A where refinements have been declared, and a class B where they have not. Class A code calls Class B code. Class B code will not see class A's refinements. In the case of dynamic scope, the refinements in use by class A would be visible to class B code, when called from code within class A.

Yes having dynamic scoping gives Perl a very powerful programming instrument.

And the lack of dynamic scoping in Ruby can cause problems elsewhere: http://news.ycombinator.com/item?id=5072925

PS. I seem fond of dynamic scoping because I've posted lots of examples here on HN: http://www.hnsearch.com/search#request/all&q=draegtun+dy...

Wow, that reminds me of the classloader magic Eclipse/OSGi does so that plugins that depend on different versions of the same library can work together in the same JVM.

That kind of local class alteration is very different from the kind of tricks done in OSGi. In OSGi a class is the same no matter what context you're in, it's just that the context you're in affects the look up from class name to class. So all the caching or optimisations you might do against classes are still valid.

Refinements mean things like method lookup are sensitive to the context and become much more fun.

As aardvark179 already mentioned this is different. There are modules on CPAN which will allow you to also do class/module path munging like this and it's fully baked into Perl6: http://perlcabal.org/syn/S11.html#Versioning

Ruby doesn't have an equivalent of Perl's 'local'.

Reply on news.ycombinator.com