From: Charles Hixson <charleshixsn@...>
Date: 2003-11-22T23:12:45+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

Yukihiro Matsumoto wrote:

>Hi,
>
>In message "Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )"
>    on 03/11/21, "Sean O'Dell" <sean@celsoft.com> writes:
>
>|This is, I think, the clearest I can make the new proposal tonight:
>|
>|http://www.rubygarden.org/ruby?InterfaceContracts
>
>...
>
>							matz.
>p.s.
>Please do not use bad words everyone.
>
Perhaps one could make assertions about parameters / methods that could 
be checked?
e.g.

class someclass < someOtherClass
    assert .kind_of(someClass, Number)
    def  initialize (foo, bar)
          assert.responds_to(foo, +)
          assert.kind_of(bar, Number)
          ...
    end
...
end

The only advantage I see of this over the normal responds_to? and 
kind_of? is that it could be enabled or disabled by either a flag or by 
a global variable   ($DEBUG  or possibly $ASSERT instead).  assert 
appears slightly special in that since it doesn't require any import 
statement, it's probably added onto Object, and also I notice that the 
"+" operator was considered as a normal method without being attached to 
any variable (and methods would need to be able to go there too).  
Perhaps that argument should be quoted?

This clearly doesn't answer all of the requirements, but it does answer 
some of them, and might assist in debugging.  (And it appears to me that 
it would be simple for someone who understood Ruby better than I do to 
implement.)  Clearly if this were to be intended as a serious checking 
tool it would need expansion, e.g. one would want a way to test that "+" 
could take either one or two arguments, and that those arguments could 
be numbers.  A benefit of this approach is that it could probably be 
bolted on without any change to the interpreter itself (at least until 
it was decided to implement interpreter flags).