From: ptkwt@... (Phil Tomson)
Date: 2004-01-18T15:10:01+09:00
Subject: Re: Fighting Ruby's bad fame

In article <af53b0ba.0401171921.7cf9b9b7@posting.google.com>,
GGarramuno <GGarramuno@aol.com> wrote:
>gabriele renzi <surrender_it@remove.yahoo.it> wrote in message
>news:<uh3g00hgtmc9f30hsm2jn17hvt1e4csf1t@4ax.com>...
>
>do a lot of things in volume and I know with ruby this would bite me.
>
>2) Localized modification of built-in classes.
>While arguably a feature of ruby, the truth is that at a large scale
>this leaves the door open to chaos.  VFX is a dynamic industry.  Oa
>normal production, you have 10 to 50 technical directors, many of them
>writing and updating scripts (and all of them with different amount of
>programming knowledge), and usually doing so without a true
>coordination.  This is not chaos, but it is a true benefit for the
>production and the facility.  Lacking namespaces or so is an issue in
>ruby and I know such an issue would not even arise for python, so this
>is also a minus for the language.

can you elaborate?  Ruby has namespaces defined by modules.

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.

However, if you really don't want anyone modifying built-in classes  then 
you can use freeze:

irb(main):001:0> Array.freeze
=> Array
irb(main):002:0> class Array
irb(main):003:1>   def foo
irb(main):004:2>     "foo"
irb(main):005:2>   end
irb(main):006:1> end
TypeError: can't modify frozen class
        from (irb):3

I suppose you could even define some sort of make_safe method that 
iterates 
through all of the built-in classes/modules (and even ones that you've 
added) and calls freeze on them, thus 
saving you from having to individually freeze each one - it wouldn't be 
that hard to do.

In fact, here's the code for doing it:

def make_safe
  ObjectSpace.each_object(){|o|
    if(o.class == Class || o.class == Module)
      o.freeze
    end
  }
end

call make_safe and all of the current Class and Method objects in 
ObjectSpace are frozen.  Maybe there should be an RCR for a commandline 
argument that actually does this when Ruby is invoked.  

However, I consider being able to (judiciously) add methods to built-in 
classes one of the great features of the language and I really doubt that 
when people are considering Ruby for a project that very many of them come 
to the fact that classes are always open and decide that it's a deal breaker.  
The kinds of 'dangerous' things you can do with Perl (for example) haven't 
seemed to hinder it too much over the years.

>
>3) Better english documentation.
>There's still the need for good english docs of all the libraries that
>are shipped with ruby.  There's also the need for documenting what
>constructs make ruby a tad faster or slower.  There's also the need
>for a solid "cookbook" a la perl or python, albeit some web docs are a
>step in the right direction.
>
>4) Better multiplatform support and libraries.
>Ruby is still somewhat inmature in dealing with scripts that would be
>run across multiple platforms.  Determining the platform, OS and OS
>version at runtime is still a pain in ruby compared to python or perl.
> A library for this is neeed asap.  

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

?

How does Perl/Python handle this any easier?

>
>6) Better emacs support.  Tools to do automatic refactoring. 
>The use of "end" as a delimiter makes it still hard in emacs to
>determine to which block it corresponds, unlike a bracket.  

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.

>Some easy
>macro is needed for that.  In some way, ruby seems to suffer from this
>a tad like python, which makes refactoring important to keep functions
>within a page long.  Thus, automatic refactoring tools would also be a
>godsend (specially if they work with emacs and vi like the python
>library refactoring does).
>
>7) Multiple inheritance.
>While this is something imo a scripting language can indeed do without
>(and I kind of like that), it does present a big headache if you want
>to integrate a C/C++ library that does depend on multiple inheritance.

It's not so bad at this point.  Swig 1.3.20 (for automatically 
wrapping C++ code) handles this by considering each of the base classes as 
modules that get mixed-in to the derived class.
For more details, see:

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

If you prefer not to use Swig, you could still borrow this idea.  Swig 
works quite well, however and it's a lot faster than 'hand' wrapping.

Phil