Live data from Hacker News

Kicking the Tires on Ruby 2.1 Preview

spin.atomicobject.com

11–16 of 16 posts

Re: Kicking the Tires on Ruby 2.1 Preview

#11
post #3

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'…

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…

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

Re: Kicking the Tires on Ruby 2.1 Preview

#12
post #11
post #3

Earlier quoted context omitted.

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…

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

2.1 changes how the method cache works. It is now hierarchical as opposed to the old global cache.

Re: Kicking the Tires on Ruby 2.1 Preview

#13
post #11
post #3

Earlier quoted context omitted.

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…

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

Those concerns voiced with 2.0's refinements before release were why they were marked as experimental, and were the driving force behind the changes made to refinements between 2.0 and 2.1.

On the 2.1, non-experimental version, he has said: "What we’re going to have as refinements in 2.1 is a paired down version that I think still provides the bulk of the functionality people wanted out of the feature without most of the pain that I was concerned about originally."

http://rubyrogues.com/124-rr-jruby-with-charlie-nutter/

Re: Kicking the Tires on Ruby 2.1 Preview

#14
post #3

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'…

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…

> 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.

Re: Kicking the Tires on Ruby 2.1 Preview

#15

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'…

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

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.

Re: Kicking the Tires on Ruby 2.1 Preview

#16
post #10

Earlier quoted context omitted.

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

Ooo excellent news, I didnt know that.
Post reply on HN