Excerpts from Carl Worth's message of Thu Aug 20 00:03:08 -0400 2009: > 1. That's not actually helping in the current case where we're trying > to do simple things like '+' and the distinction between Set and > Array is causing problems. (See the patch where we're having to add > .to_a and Set.new to coerce things.) So, here, at least things are > falling down. So somehow something in ruby isn't living up to the > concept here.
You're correct. The difference between fixing this in Ruby vs fixing this in a strongly typed language though is that you could implement Set#join such that the code expecting an array wouldn't know the difference _or_ you could have that code use kind_of?(Array) to ensure it was getting the type of argument it was expecting. Both are technically correct. In a strongly typed language, you'd have to modify the acceptable arguments (function definition) and ensure everything that called the function passed something acceptable or provide an overloaded version (if you're working with a language that supports it). Those are correct solutions too. > > Your code doesn't care _what kind_ of object it gets as long as it > > knows _how_ to talk to it. > > 2. Even with the "duck typing" I'd still like to express this > constraint in a way that is decidable statically. I've definitely > failed as a programmer if a user sees a runtime exception like > that. Sytems with sophisticated runtimes are very interesting to > me. It's just discouraging to me that so many such systems fail to > actually help me avoid problems like this before the user is > running my code. Bugs are bugs! :) Static typing only goes so far to prevent some of this stuff...just look what you can make a C compiler do with funky casts. I take your point though. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting.
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
