Baschino wrote:
> 
>...
>
> With Ruby, however, the whole stir-up that an advancement causes such as can
> 
> be seen in the discussion of PEP238 on the Python news group can easily be
> 
> avoided in Ruby thanks to its inherent deeper OO character and the absence
> 
> of a dichtomy between built-in types and classes, i.e. you can just
> redefine the /-operator rather than making an incompatible change in the
> language.

For those who don't know, the Python world is currently engaged in a
heated argument about whether to change division from 5/2==2 to 5/2==2.5
Ruby has the same int/int behaviour and I have a feeling that you'll
have the same argument someday. Baschino claims that Ruby's support for
overriding basic type behaviours will solve that problem automatically.
I don't believe that is true.

Let's say a Ruby programmer overrides division so that "/" means
something different. That change is visible globally, right? It doesn't
just affect the module you are working on. As soon as you combine your
overloaded object with other people's code (e.g. the standard library!)
you'll break that code. So really everybody needs to agree on the
semantics of division.

I tend to think that both Python and Ruby made the wrong decision but
many people (especially those who have a long history with programming
in statically typed languages) disagree with me. I am therefore one of
those that are glad that Guido is biting the bullet even if it breaks
code.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook