>can you elaborate?  Ruby has namespaces defined by modules.
>

Yes, but not good enough.
Compared to Perl or Python, include is missing the ability of Perl's use or
Python's import command to just bring only certain parts of the module into the
current namespace.
In perl, you can do:
    use Module (:func1 :func2);
and in python:
    from Module import :func1, :func2

And only those two functions/classes/variables get imported into the current
namespace.   Ruby's include seems to be an all or nothing proposition,
unfortunately.

>As far as modifying builtin classes goes, we're hearing a lot in 
>this thread about how this is a problem. Personally, I don't see it as 
>long as you're not redefining predefined methods

Correct.  I do see this as a benefit of ruby, too, but not without some form of
leash in the language to have the ability to keep the addition/modification
local or under the programmer's control.
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.  Freezing the class is no use as I WANT to be able to do that for
my own class.
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.
While you can do such things in perl or python, too; those things are usually
discouraged while in the ruby way, they are 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.
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.
Otherwise, it IS a deal breaker.


>
>Perhaps, but I've written lots of cross-platform scripts.  How hard is it 
>to do:
>
>  case PLATFORM
>    when /win/
>      #do Windows things
>    when /nix/
>      #do Unix things
>    else
>      #whatever
>  end

Well, that's the issue isn't it?  What is #whatever?
Quick!  Can you tell me how do I get the terminal's screen size in all these
platforms: win32, dos, linux, HP, sun, irix, ming32, cygwin, osx, mac9?
You know?  Great!  Now, can you tell me how ruby defines PLATFORM on each OS,
as I don't have each of those machines handy?
Now, better yet, can you tell me how can I distinguish the OS name and version
in ruby, since PLATFORM does not tell me that?
Those are the things missing from libraries and having at least ONE library
where all possible alternatives are listed would be nice.
In the case of perl, this is handled more or less as bad as ruby, but there are
a bunch of libraries that have been tested along the years that have a huge
list of these possibilities for you to learn from.
In the case of python, PLATFORM is much more simplified, as os.name can be only
one of  'posix', 'nt', 'dos', 'os2', 'mac', 'ce' or 'riscos'.  No surprises
there and no need for any regex'es.  Nothing weird like "i386-win32".

>
>This works in vim.  I'm not an emacs user, but if they could get it 
>working with a vim script, I'm sure it can be done in emacs lisp.

Yes, I'll take a look at writting an emacs macro for this.  But still,
refactoring tools would be much more useful.

>
>http://www.swig.org/Doc1.3/Ruby.html#n19
>

Yes, been playing with swig1.3.  Like it a lot, but it is missing some needed
stuff for ruby.
For example, ALL #define constants are translated to ruby.  Even those that are
invalid ruby constants like those starting with underscores (and there does not
seem to be a way to ignore those, as with methods).
There seems no way to have swig automatically expose protected methods, which
is quite needed.
There is no %rubycode available like the %pythoncode directive in python mode
to create additional .rb code files.
And I'm not sure mixin's really can deal with multiple inheritance 100%
properly.  Sure, methods are easy.  I am concerned more about dealing with
variables (both class and instance), thou, as from my quick glance at it,
modules seem to be somewhat limited in this aspect.