Proposed Solutions (Monkeypatching)

[Trans]

Hi Trans,



Rails has increased Ruby's mind share significantly and perhaps first
time Ruby is being used to built applications that are really complex
and large. For example, I do significant work in Ruby without Rails
and my Rails project size is currently 71498 lines ( including
plugins that I am using, but not the framework and not counting
Javascript, rhtml,css,xml,yaml ).

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" ;P

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

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.

 

[s.ross]

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.