On Thu, 15 Jun 2000 16:35:37 -0500, Conrad Schneiker
<schneik / austin.ibm.com> wrote:

>> >> So why not do this? Make Ruby a
>> >> language with both static and dynamic type.
>> >
>> >I think this might be possible, but I think there would be all sorts of
>> >complex issues concerning the often subtle and indirect interactions of
>> >these 2 very different styles of doing stuff.
>> >
>> I don't think so. You need a casting mechanism ( and a null object
>> for when you can't cast ) between the two. You have method parameters
>> which are either typed or untyped. If you call a method with a an
>> untyped object and that method  requires a type, you do a typecast
>> before you pass it. If you call a method requiring an untyped object
>> with a typed object, the compiler simply ignores the type information.
>
>"simply ignores the type information"? Well, I'd be surprised if that didn't
>lead to many violations of the principle of least surprise in practice,
>especially when you start mixing up lots of library modules and such written
>by many people. (I wouldn't mind being surprised in this case, however.)

Any more  then passing the wrong type in an untyped variable?
You could require that a person convert a typed variable to an untyped
variable before you pass it, but I don't see that that helps in
anyway. You already know that the call uses untyped objects, and so is
not type safe.