olczyk / interaccess.com (Thaddeus L. Olczyk) writes:

> So why not do this? Make Ruby a language with both static and
> dynamic type.

One of the joys of Ruby is it's uncluttered syntax and simple
semantic.

Behind tha lies a sophisticated object model.

> You can declare an object to be of a type (eg MyClass MyObj ) in
> which case it is statically typed or you can declare an object
> untyped (eg untyped myObj or dynamic myObj ).

In Ruby, objects are already types (according to one definition of the 
word)--they respond to a certain set of messages. You can make objects 
immutable by freezing them. One of the impacts of this is that you
can't add to the set of messages handled by a frozen object. Is this
what you wanted?

I suspect not. My guess is that you wanted to be able to define the
type of a variable.

This would be impossible in Ruby, as type signatures are mutable.

For example

     def fred(String param)

What's the type of 'param'?  String, you say. OK, but then


    class String
       def +
          raise "Sorry, no concatenation today"
       end
    end

I've just changed the meaning of String. Should Fred now not accept
such modified strings? How would it know. And I've just changed every
string in the system (including "Sorry, no concatenation today").


I've used strongly typed languages in the past. I thought it would be
bad to go to a language where types are basically irrelevant. I was
wrong--I come across bugs because of this very, very infrequently, and 
my productivity is so much higher (I'd say by an order of magnitude)
that the occasional problem is easily accounted for.


Of course, your milage may vary.


Dave