From: bwalton@artsci.utoronto.ca (Ben Walton)
Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set
Date: Thu, 20 Aug 2009 20:16:23 -0400 [thread overview]
Message-ID: <1250813245-sup-6519@ntdws12.chass.utoronto.ca> (raw)
In-Reply-To: <1250740488-sup-1624@yoom.home.cworth.org>
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/575e53e4/attachment.bin>
next prev parent reply other threads:[~2009-08-21 0:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 20:41 Wirt Wolff
2009-08-20 0:31 ` Carl Worth
2009-08-20 2:57 ` Ben Walton
2009-08-20 4:03 ` Carl Worth
2009-08-21 0:16 ` Ben Walton [this message]
2009-08-24 18:13 ` William Morgan
2009-08-25 7:44 ` Nicolas Pouillard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250813245-sup-6519@ntdws12.chass.utoronto.ca \
--to=bwalton@artsci.utoronto.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox