Kicking the Tires on Ruby 2.1 Preview

http://spin.atomicobject.com/2013/09/26/ruby-2-1-preview/

by micahalles • 13 years ago

37 15 13 years ago

spin.atomicobject.com

jrochkind12• 13 years ago

Refinements, why, matz, why?

In a large complex program with many dependencies, they are going to make debugging an nightmare, figuring out where the method you were calling is actually defined. And lead to weird hard to diagnose bugs where you call a method with a differnet definition than you expected.

And the use cases that justify refinements is entirely large complex programs with many dependencies, right? They're supposed to actually _reduce_ bugs and debugging challenges from monkeypatching... but nobody seems to actually think they do except matz.

Is _anyone_ who works on well-known large complex programs with many dependencies -- actually on record as supporting refinements, subsequent to the analyses that showed what a mess they'd become?

Why, matz, why?

ufmace• 13 years ago

My understanding is that refinements are more of a limitation of existing monkeypatching functionality though. Like before, if you needed to monkeypatch something, you had to re-define the method system-wide. This seems like it allows you to have the monkeypatch only apply in the modules that you need it to, and to define it with a special refine keyword that's easy to search for.

Then again, many of the major gems that I've worked with so far define methods in various dynamic ways, making it challenging to figure out what code it's actually running. Hello ActiveRecord?

ssmoot• 13 years ago

You could always extend the singleton object before to avoid global monkey-patching.

But the real lesson is probably just if you're not writing ActiveSupport, don't do global monkey patches at all. Favor inheritance and composition. Especially in your own libraries where it's easier to ensure a global patch doesn't break your code.

dewind• 13 years ago

I'll refer to Nutter on this one. Refinements appear to be a method caching nightmare.

http://blog.headius.com/2012/11/refining-ruby.html

dragonwriter2• 13 years ago

My understanding is that refinements are more of a limitation of existing monkeypatching functionality though.

They are an alternative rather than a limitation, since you can still do regular monkeypatching, you just now have an option to do things that are less intrusive.

gum_ina_package• 13 years ago

You can always not upgrade. It's not a fun option, but an option never-the-less. Or just don't use refinements.

rurounijones3• 13 years ago

Seeing as other ruby implementations (rubinius and jruby) have been very iffy on refinements and may not implement them it is probably best not to use them at all if possible.

jrochkind12• 13 years ago

I won't use refinements, but if open source code I'm using uses them, I still get to debug them.

Yes, yes, I know, I can analyze any open source code before using it and not use it if it uses refinements, or I can simply never use any Not Invented Here code at all.

I can do many things, it is indeed a wonderful free country.

dopamean• 13 years ago

I'm interested in seeing how refinements actually affect things. Matz is so set on it but so many smarter people than me think it's a mistake.

shawn423• 13 years ago

+1 I wonder if anyone has a branch of what the "refined" activesupport would look like.

rurounijones3• 13 years ago

I still wonder why a lot of activesupport's monkey patches are not merged into ruby's stdlib proper. Sure some of it is quite rails specific but things like String#constantize is just so damn handy it should be in ruby stdlib.

Kicking the Tires on Ruby 2.1 Preview

Related Stories