Re: Fighting Ruby's bad fame

On Monday, January 19, 2004, 1:05:02 PM, GGarramuno wrote:

> I've been using ruby for about 1 week & 1/2 and already run into that.  I
> created String#expand_tabs() function in a module of mine only to find a
> similar (but less efficient implementation) of that function in another popular
> ruby library.

Could you send me the efficient implementation? :)

> This to me already points out the huge issue of name clashes.  In this case, it
> is not biggie as both functions do the same, but... it already sent shivers
> down my spine.

You DO test code before deploying it into a critical productiohn
system, don't you?  What's so bad about name clashes?  You find them,
fix them, and move on.  Same as any other kind of coding error.  And,
short of clashing with a library whose explicit purpose is to extend
the built-in classes, I bet you don't even find any name clashes. :)

> While you can do such things in perl or python, too; those things are usually
> discouraged while in the ruby way, they are not.

Not true.  Some people like them, some don't.  Good libraries take
care not to impinge on public namespaces unreasonably.  Experimenting
with modified classes is quite encouraged in Ruby.  Overdoing it is
not.

> And as I mentioned before, the include's of the other languages are
> better than ruby's as the coder can load the modifications
> selectively, too.

I don't like the sound of that "feature".  A well-designed library
should be loaded in full.  In OO languages especially, you either load
a class or you don't; you don't pick and choose methods.

Larger libraries may have several classes in a module, which can be
selectively loaded by loading different files (require "foo/a",
require "foo/b").

Selective importing of pure module functions *may* have some benefit,
but still sounds pretty average.

> Personally I like this phisolophy of ruby, but I NEED to have the ability to
> easily keep changes to base classes local to my class or in an easy way to
> revert them.

At the risk of re-igniting an old flamewar, no you don't.  Not until
you prove that you need it anyway.  At the moment it's mere paranoia.
No offense intended; we've all been there I'm sure.

I don't rule out the possibility of you proving that you need the
feature.  And I think that namespaces/behaviours would be nice.  You
have certainly hit on a controversial Ruby feature, and interesting
discussion on it is always ... well, interesting.

> Otherwise, it IS a deal breaker.

Take responsibility for your own code, and scrutinise third party code
you use.  Run RDoc on them and see if any built-in classes appear.
Use Ruby to prototype a solution and then ask what's wrong with it.

Cheers,
Gavin