From: “Rule.rule” [email protected]
It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
there:
Ruby (programming language) - Wikipedia
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.
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