Hacker News Reader

Comment by kaiuhl | Hacker News Reader

The most convincing argument as to why not to include refinements in the Ruby spec comes from alternative implementations like JRuby and Rubinius. Method dispatch will need to be vastly more complex (and have scope-limited caching) to support this feature. Much, much slower. Folks using these implementations are still on the fringe, but it seems wrong to add a feature to Ruby that makes both more complicated code and slower running code.

Wasn't Object#source_location added in 1.9 to help folks understand and find method definitions in code? Shouldn't we simply test our code to ensure it functions correctly and not force additional semantics all the time to fix a rare issue?

View on HN

> Shouldn't we simply test our code to ensure it functions correctly and not force additional semantics all the time to fix a rare issue?

The problem is you can't. If library A and B define String#to_param differently for internal use you can't use them together, while both of them are perfectly correct on their own.

I've been writing Ruby professionally for six years and this has never been an issue for me or folks I work with. Can you give a single example where you found a conflict in libraries that broke your application?

Rake::RemoteTask (a dependency of Vlad) defines a bunch of stuff on Kernel, including #role. For whatever reason, if an ActiveRecord model includes role as a property, things break in weird ways.

Reasonably easy to work around by aliasing/undefing Kernel#role to #server_role or something, but amusingly that would be something that could be fixed by refinements (though I'd rather see something more like Thor, that's not run toplevel).

I ran into a nasty bug a while back which came down to a conflict between two JSON libraries in their definitions of #to_json on core classes.

I have seen issues quite a few times, and they are serious headaches to fix when they come about. I've had libraries implement Rails utility methods slightly differently, or conflicting implementations of monkeypatches on S3 libraries.

While it's not incredibly common, disrespecting namespace concerns is a sure road to problems.

I think the same. For 99% of Ruby programmers speed is bigger issue than monkey patches conflicts.

Maybe refinements should evolve into some MRI diagnostics mode.

Reply on news.ycombinator.com