Kicking the Tires on Ruby 2.1 Preview
spin.atomicobject.com
Kicking the Tires on Ruby 2.1 Preview
1–10 of 16 posts
Re: Kicking the Tires on Ruby 2.1 Preview
#2Refinements, 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?
Re: Kicking the Tires on Ruby 2.1 Preview
#3Refinements, 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'…
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?
Re: Kicking the Tires on Ruby 2.1 Preview
#4Refinements, 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'…
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 t…
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.
Re: Kicking the Tires on Ruby 2.1 Preview
#5Refinements, 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'…
You can always not upgrade. It's not a fun option, but an option never-the-less. Or just don't use refinements.
Re: Kicking the Tires on Ruby 2.1 Preview
#6I'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.
Re: Kicking the Tires on Ruby 2.1 Preview
#7I'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.
+1
I wonder if anyone has a branch of what the "refined" activesupport would look like.
Re: Kicking the Tires on Ruby 2.1 Preview
#8Refinements, 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'…
You can always not upgrade. It's not a fun option, but an option never-the-less. Or just don't use refinements.
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.
Re: Kicking the Tires on Ruby 2.1 Preview
#9I'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.
+1 I wonder if anyone has a branch of what the "refined" activesupport would look like.
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.
Re: Kicking the Tires on Ruby 2.1 Preview
#10Earlier quoted context omitted.
You can always not upgrade. It's not a fun option, but an option never-the-less. Or just don't use refinements.
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.
Charles Nutter (of JRuby) has said that many of his main complaints on refinements have been resolved. His original rant can be found here: http://blog.headius.com/2012/11/refining-ruby.html