From: "Rule.rule" <
[email protected]>
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 writerubycode that evadesruby'stype 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++.
InRuby, an object's type is essentially related to which set
of messages that object responds to at any given point in time.
Classes, inRubyare more useful for implementation inheritance,
than in establishing an object's type. Rubyis 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.)
InRuby, 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 evadeRuby'stype 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 inRubydoes 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>
InRuby, 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?
=> #<Psychotic:0x279af38>
Here, we have an object that will happily respond to ANY method
called on it...
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:
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!)
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
