

Refinements in Ruby — Monkey patching for friendly monkeys - judofyr
http://timeless.judofyr.net/refinements-in-ruby

======
fizx
This feels a lot like scala implicit conversions/views made into idiomatic
Ruby.

In scala, you could write an "implicit function" that converts Foos to Bars.
If and only if you imported the function, you could then (1) pass an instance
of Foo to a function accepting Bars and (2) call methods of Bar on a Foo.

For example, if you defined an implicit mapping from Int to
IntWithTimeMethods, you could then call something like 1.seconds_from_now, and
get a Time back. You can see something like this at work in
[https://github.com/robey/xrayspecs/blob/master/src/main/scal...](https://github.com/robey/xrayspecs/blob/master/src/main/scala/com/twitter/xrayspecs/Time.scala)

In scala, it's not required that the class you convert to is a subclass of the
original, but it's a really common use case. This "refine" behavior gives you
this same ability, but just with an anonymous subclass.

FWIW, I like Scala's implicit conversions. Usually, I see them with things
like 1.seconds, or object.toJson, and then you just look among the imports for
something referencing time or json. I guess people could think up absurd uses,
but then, those people were writing bad code anyways.

------
techarch
Thanks for the summarized analysis Magnus. The syntax for defining and using
refinements looks very clean. I'm looking forward for this feature to be
included natively.

------
rue
I think Classbox is the better way to go, but this is an improvement. The
performance hit is currently very significant, but I suspect it can be
optimised to a negligible level.

As with the .append_features hack, I think it is only good that refinement in
no way implies inclusion. It will probably be better to keep the two types of
modules explicitly separate.

------
xentronium
I have mixed feelings about this.

It's good because you gain an ability to scope your monkey patches.

It's bad because it incentivizes monkey-patches.

~~~
generalk
I don't get it. What's bad about incentivizing monkey-patches that _don't_
interfere with other code?

~~~
jonathanwallace
The only thing that comes to mind is its not immediately obvious when source
diving when a piece of code has been refined or redefined.

IMO, this is the justified cost of flexibility provided by monkey-patching.

~~~
jerf
This isn't specifically a problem with monkeypatching. Not knowing what is in
scope right now is a generalized problem with object oriented programming.
Scoped monkeypatches doesn't really add to the problem, IMHO.

(Please note I don't even mean that as a criticism of OO per se. Like
everything else, it has costs and benefits, and that is, well, actually a bit
of both. Things being hidden from you is annoying, but if you switch to
something like Haskell you'll find that everything being shown isn't always
entirely cool either.)

------
giantsquid
Just a poor idea

