From: Gavin Sinclair Date: 2004-01-19T22:20:52+09:00 Subject: 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