On Friday 21 November 2003 11:57 am, Alan Chen wrote:
> Peter <Peter.Vanbroekhoven / cs.kuleuven.ac.be> wrote in message
> news:<Pine.LNX.4.44.0311211531540.23782-100000 / merlin.cs.kuleuven.ac.be>...
>
> > Anyway, I'm not contesting that The Ruby Way works. But nobody showed
> > evidence that The Ruby Way With Optional Interface Checking doesn't work
> > better, though people tried based on flaws of other languages.
>
> One problem that I can see is that Optional Interface Check could
> impose a significant cost on those who aren't interested in
> type-checking. Primarily, integrating type-checking code with
> non-type-checking code could be a burden. I really don't want to be
> browsing through ruby code libraries thinking "is this a type-checked
> library?" Or worse, downloading some ruby code only to find that it
> didn't mention that type checking was a core approach of the library.
> For these reasons, I think the burden should be on the type-checking
> implementors to be able to disable the checking with no or few ill
> effects. Hmm, I guess this comment applies slightly more to
> interface/inheritance checking systems instead of "method signature"
> based systems.

Most libraries only expect native Ruby types or their own types.  Rarely do 
they expect you to construct a type all by yourself, you're usually given a 
factory method or a class you can call #new on.  So even if they did 
interface checking, the compliance would already be there for you.  Also, it 
doesn't affect your existing code because it's allowed to live alongside 
non-interface-checked code.

	Sean O'Dell