# Proposed Solutions (Monkeypatching) **URL:** \ **Category:** Ruby\ **Created:** [February 28, 2008, 10:44pm UTC](https://www.ruby-forum.com/t/proposed-solutions-monkeypatching/130515 "2008-02-28T22:44:57Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [February 28, 2008, 10:44pm UTC](https://www.ruby-forum.com/t/proposed-solutions-monkeypatching/130515/1 "2008-02-28T22:44:57Z")
On Feb 28, 12:59 pm, hemant [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > preventative obstruction is going to make anything better, it will > > Too often, I have seen people blaming everything to Rails, but I do > not think its true in this case. I’m not blaming Rails. Just pointing out that Rails via ActiveSupport gets pretty freaky freaky with the extent and methodology by which it uses extensions. While not 100% true, on the whole loading ActiveSupport is an all or nothing affair --and ActiveSupport does a fair bit of core/standard method overriding. So like it or not, people learning Ruby via Rails follow those patterns. > In the first link that I posted, whose fault it is? The fault was trying to have it both ways. They should have just depended on ActiveSupport. If they didn’t want to do that then they should have used a unique name (#aws3\_underscore) or not extended. Moreover, bugs happen, we fix them. > I have 103 gems > installed on my machine, and not counting > Rails libraries and facet , I still have around 5 or 6 of them, which > are modifying core classes one way or the other. > > Trans, often on #ruby-lang I have heard from experienced rubyists why > they avoid facet. I do not think, its a problem of rails. > Ruby has grown and is being used by people with varying skills. I do > not think, features that help people in avoiding these problems is > bad. “Often”? You mean “Austin” 😜 But seriously, the fact that Facets extends core and standard library has nothing to do with it’s quality. Extensions are what Facets is primarily all about --and for good reason. Standards help the very issue your worried about! Now, some people don’t like the idea of such a large library. That’s fine. And I know such persons often use Facets as a copy and paste resource too. That’s fine too. Unfortunately I don’t think they realize they’d be better off with a dependency, for some of the very reasons you suggest about the risks of extension. But that’s their choice to determine, of course. And I’m certainly not going to take it from them. Also, understand Facets has taken a long time to mature and still is in some respects. But long gone are the 1.7 days when a good deal of the library was thrown in just to see how it pans out. Facets is much more mature and refined now. In fact, with the exception a few libs, it is pretty solid. And as aways Facets allows you to pick and choose just the portions that work for you. There is no need to load the whole thing. > As a last note, I will leave you with this: > > [http://blog.brightredglow.com/2008/1/17/evil-can-be-dangerous](http://blog.brightredglow.com/2008/1/17/evil-can-be-dangerous) > > So, no its not specific to Rails. Its not a problem either, but we can > do better. As I said before, overriding Ruby core/standard methods is very dangerous. One should only do so under very limited circumstance. And that’s an important point. There are two forms of extension, and it’s important not to to mix them together: overriding methods in core/standard classes/modules and adding new methods to existing classes/modules. I suppose few even realize for all of Facets’ method extensions (with maybe one or two minor exceptions) there are NO OVERRIDES. So core/standard extension are a moot point. If you override a core/standard method, you’re playing with fire and you better damn sight know what you are doing. One can argue that some “freeze” mechanism should be added to those, or at least the most important of those. I wouldn’t much care, as long as there was a reasonable back door for special cases, and really I doubt few would even notice (except maybe the Rails team ;). Most people know better and are not overriding core/standard methods. It is the other ones, the add-ons, that are the big deal. Those are the extensions everyone find so useful. Putting some kind of “freeze” on those would KILL Ruby. If you think that is “evil” then you should be using another language, b/c the ability to extend is fundamental to Ruby’s very nature. What people need to be doing, rather then scaring less seasoned Rubyists into thinking they should give up their liberty for some superficial security, is spreading the message about good extension practices. As I have said before a) good tests go a long way, b) unique extensions should use unique names and be considered very carefully if needed at all, and c) for potentially common extensions seek out shared libraries --and contribute to them, to help the community form strong tertiary standards. T. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [February 28, 2008, 11:02pm UTC](https://www.ruby-forum.com/t/proposed-solutions-monkeypatching/130515/2 "2008-02-28T23:02:33Z")
On Feb 28, 2008, at 1:43 PM, Trans wrote: > So like it or not, people > learning Ruby via Rails follow those patterns I’m going to take SWAG and say that people learning Ruby on Rails don’t read the source code. This is based on my reading of the mailing list. Because 37s has taken a given approach does not mean that every Rails adopter will feel confident enough in their ruby\_fu to do the same. I’ll go one step further: I don’t think most Rails programmers read the code in the plugins they install. I don’t think Rails is introducing problems or misusing features in the language. Many, if not most Rails programmers accept the magic as just that: Magic. They don’t feel like magicians, just people looking to get their jobs done in a more pleasant way. When you consider all the angles of this, don’t neglect testing. Some very useful test methodology relies on extending classes, and I think it strengthens Ruby as a development platform. Finally, in the spectrum of hard-to-track-down bugs, where 1 is a syntax error and 100 is a concurrency bug, I would think problems introduced as a result of extending a base class fall somewhere near 25. My experience is that binary searching the unexpected behavior with puts statements and then probing with ruby-debug is normally enough.