Re: Ruby type-safe? Ruby strongly/weakly typed? Ruby pitfalls?

From: "Rule.rule" <[e-mail]>
>
> On Feb 22, 2:08 am, Bill Kelly <[e-mail]> wrote:
>
>> Anyway - Ruby has strong/dynamic typing
>
> Dynamic, sure.
> But re strongly, yes, I have seen this claim in several places
> (including from Matz).
> As I pointed out on wiki, though, it seems to depend on what
> definition one refers to.
> It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
> there:
>     http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
> 
> But Ruby immediately clashes with my own "intuitive concept" of
> "strongly typed",
> when you can do things like:
>  x = 2; x = "a"
> without getting an error,
> and you also have untyped lists/arrays, etc, in the language.

OK; well... the closest to what I had in mind appears to be #6.
However, the caveat warning that #6 is difficult to prove 
mathematically seems spurious to me.

If one can write ruby code that evades ruby's type system, it's
a bug in the language implementation.  So it's like having a caveat
for C++ that says, the compiler is supposed to generate valid
assembly code for all valid input statements, but this is very
difficult to prove mathematically. . . . Yes, it may be difficult
to prove that there are no implementation bugs in C++ compilers,
but we don't go around adding asterisks to that effect when
talking about C++.

In Ruby, an object's type is essentially related to which set
of messages that object responds to at any given point in time.
Classes, in Ruby are more useful for implementation inheritance,
than in establishing an object's type.  Ruby is much more dynamic
than that; a given object need not necessarily respond to all
the methods provided by its superclass (it could undefine some
or all of those methods, for example.)

In Ruby, variables don't have types, objects do.  And an object's
type cannot necessarily be usefully determined by looking at
the object class's inheritance hierarchy.  Nonetheless, one 
cannot evade Ruby's type system as one can in C++:

  class Dog { public: void bark(); };
  class Cat { public: void meow(); };
  Dog *dog = new Dog();
  ((Cat *) dog)->meow();

In C++, the above results in undefined behavior. (Possibly crash.)
The equivalent in Ruby does NOT result in undefined behavior.

  class Dog; def bark; puts "Woof!"; end; end
  class Cat; def meow; puts "Mew!"; end; end

  cat = Dog.new
  cat.meow

  NoMethodError: undefined method `meow' for #<Dog:0x2c6cf40>

In Ruby, we have merely tried to send an object a message it 
doesn't respond to.  That is a perfectly well-defined scenario
in the language, and the type system has not been violated or
evaded.

If it helps clarify, the following statements:

  cat = Dog.new
  cat.meow

...are semantically equivalent to:

  some_object = Dog.new
  some_object.send(:meow)

...In the latter, it should be clear that we are merely
attempting to send an object referenced by the variable
<some_object> a particular message, :meow.

Ultimately, it's really a fairly elegant and beautiful and
simple type system: Messages are sent to objects, which either
respond to them or they don't.

Sadly, I'm no math whiz - but "objects respond to messages or
they don't" doesn't strike me as likely to be as hard to 
prove mathematically as #6 on the wiki page tries to claim.

One more example...

What should we call the 'type' of the following object?

>> class Psychotic
>>   def method_missing(name, *args)
>>     if name.to_s.length == 6
>>       raise(NoMethodError, "I don't like six-letter method names, such as #{name}!")
>>     else
>>       puts "Awesome! I'm so happy you called my method #{name} !"
>>     end
>>   end
>> end
>> x = Psychotic.new
=> #<Psychotic:0x279af38>

Here, we have an object that will happily respond to ANY method 
called on it...

>> x.hello
Awesome! I'm so happy you called my method hello !
>> x.lets_be_friends
Awesome! I'm so happy you called my method lets_be_friends !
>> x + x
Awesome! I'm so happy you called my method + !

...EXCEPT methods of exactly six letters:

>> x.hooray
NoMethodError: I don't like six-letter method names, such as hooray!
        from (irb):46:in `method_missing'
        from (irb):55
        from :0

What is the type of that object?  (I'm not sure what to call its type,
but nevertheless its type still can't be disabled or evaded!)


Welcome to Ruby.  <grin>


>> But static typing is not required for "real-life" development.  :)
> 
> Obviously not, I have also seen a few sizable systems entirely built
> in PHP or Perl or whatever,
> after they started out as a "pilot" and later they didnt have the
> funds to rebuild them,
> decided to go live with what they had, and kept expanding on it...
> 
> But how easy and fun are they to maintain and extend, when over the
> years the
> original creators leave the project and new people join, etc?

In 2.5 decades of programming so far, the two worst codebases
I've had to maintain so far were in C, and Java.  I wouldn't
blame that language for that, just the coders.


Regards,

Bill