Proposed Solutions (Monkeypatching)

On Feb 28, 12:59 pm, hemant <[e-mail]> wrote:
> Hi Trans,
>
> On Thu, Feb 28, 2008 at 10:57 PM, Trans <[e-mail]> wrote:
> >  I think there is deep misunderstanding about all this. The main issue
> >  is really that Rails has added so many extensions to Ruby that
> >  inexperienced Rails programmers follow suit and extend Ruby willy-
> >  nilly. But that's not Ruby's problem. Ruby is an open "agile" language
> >  --it lets you override almost any part of the system. Yes, that can be
> >  "dangerous", but it can also be extremely powerful. It's up to the
> >  programmer to consider their usecase and make the call. No amount of
> >  preventative obstruction is going to make anything better, it will
> >  only make life more difficult for those who use MP appropriately. I
> >  personally think Ruby has too many meta-obstructions as it is. I
> >  certainly don't want more.
>
> 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.