I got the impression that duck typing is the "right" way to do things
in Ruby. However, the Ruby Standard Library itself doesn't seem to use
duck typing. Consider the following example:
irb(main):001:0> require 'set'
=> true
irb(main):002:0> s = Set.new
=> #<Set: {}>
irb(main):003:0> s.superset? 0
ArgumentError: value must be a set
It seems like the "superset?" method explicitly checks that its
parameter is a set. This is approach #1 in the "duck typing" article
above, which the article claims is not "the Ruby way".
So, what gives? If it's wrong to "try to make Ruby do Static Typing"
(as the article says), then why does the Ruby Standard Library do it?
I got the impression that duck typing is the "right" way to do things
in Ruby. However, the Ruby Standard Library itself doesn't seem to use
duck typing. Consider the following example:
irb(main):001:0> require 'set'
=> true
irb(main):002:0> s = Set.new
=> #<Set: {}>
irb(main):003:0> s.superset? 0
ArgumentError: value must be a set
It seems like the "superset?" method explicitly checks that its
parameter is a set. This is approach #1 in the "duck typing" article
above, which the article claims is not "the Ruby way".
So, what gives? If it's wrong to "try to make Ruby do Static Typing"
(as the article says), then why does the Ruby Standard Library do it?
irb(main):001:0> require 'set'
=> true
irb(main):002:0> s = Set.new
=> #<Set: {}>
irb(main):003:0> s.superset? 0
ArgumentError: value must be a set
It seems like the "superset?" method explicitly checks that its
parameter is a set. This is approach #1 in the "duck typing" article
above, which the article claims is not "the Ruby way".
So, what gives? If it's wrong to "try to make Ruby do Static Typing"
(as the article says), then why does the Ruby Standard Library do it?
Good question. This is the offending method:
def superset?(set)
set.is_a?(Set) or raise ArgumentError, "value must be a set"
return false if size < set.size
set.all? { |o| include?(o) }
end
There's certainly no good reason to refuse to accept other classes that
has #size and #all?
I suspect one reason for this is that without it #superset? the way
it's written will just quietly return the wrong result if you pass it a
FixNum (like you did)
That's one of the pitfalls of duck typing - sometimes things will look
like they should work, and return results that sometimes may even look
right, and things will just quietly fail.
In this case, the issue is the FixNum#size returns the storage size of
the number (4 on my platform), and so if you test it with Set's smaller
than 4 items, it will just return false.
A better way would be change the "set.is_a?(Set)" to
"set.respond_to?(:all?)" (and optionally handle that case properly). So
a possible replacement that handles both arrays (and anything else
supporting #size and #all?) as well as anything that will work with
Set#include? (such as FixNum)
def superset?(set)
if set.respond_to?(:all?)
return false if size < set.size
set.all? { |o| include?(o) }
else
return false if size < 2
include?(set)
end
end
> I'm new to Ruby, so please excuse any ignorance on my part. I read the
> following article about Ruby and "duck typing":
>
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511
>
> I got the impression that duck typing is the "right" way to do things
> in Ruby. However, the Ruby Standard Library itself doesn't seem to use
> duck typing. Consider the following example:
>
> irb(main):001:0> require 'set'
> => true
> irb(main):002:0> s = Set.new
> => #<Set: {}>
> irb(main):003:0> s.superset? 0
> ArgumentError: value must be a set
>
> It seems like the "superset?" method explicitly checks that its
> parameter is a set. This is approach #1 in the "duck typing" article
> above, which the article claims is not "the Ruby way".
>
> So, what gives? If it's wrong to "try to make Ruby do Static Typing"
> (as the article says), then why does the Ruby Standard Library do it?
It is just giving you a nicer error message. Otherwise, this might happen:
irb(main):003:0> def foo(s) s=s.to_set end
=> nil
irb(main):004:0> foo
=> #<Set: {}>
irb(main):005:0> foo Set.new
=> #<Set: {}>
irb(main):006:0> foo 0
NoMethodError: undefined method `to_set' for 0:Fixnum
from (irb):3:in `foo'
from (irb):6
Note that there must be an exception of some kind if the parameter is
inappropriate. And no, this is not static typing.
Kind regards
robert
Yes, there must be an exception of some kind if the parameter is
inappropriate. The question is whether to explicitly check the type of
the parameter and throw a nicer exception, or to explicitly *not* check
the type of the parameter and let the exception happen where it may
(i.e. when a needed method does not exist).
Arguments can be made for both sides, but which is considered the "best
practice" for Ruby development? The Ruby Standard Library suggests it
is the former, but the article I referenced above suggests it is the
latter.
I got the impression that duck typing is the "right" way to do things
in Ruby. However, the Ruby Standard Library itself doesn't seem to use
duck typing. Consider the following example:
irb(main):001:0> require 'set'
=> true
irb(main):002:0> s = Set.new
=> #<Set: {}>
irb(main):003:0> s.superset? 0
ArgumentError: value must be a set
It seems like the "superset?" method explicitly checks that its
parameter is a set. This is approach #1 in the "duck typing" article
above, which the article claims is not "the Ruby way".
So, what gives? If it's wrong to "try to make Ruby do Static Typing"
(as the article says), then why does the Ruby Standard Library do it?
It is just giving you a nicer error message. Otherwise, this might happen:
irb(main):003:0> def foo(s) s=s.to_set end
=> nil
irb(main):004:0> foo
=> #<Set: {}>
irb(main):005:0> foo Set.new
=> #<Set: {}>
irb(main):006:0> foo 0
NoMethodError: undefined method `to_set' for 0:Fixnum
from (irb):3:in `foo'
from (irb):6
Note that there must be an exception of some kind if the parameter is
inappropriate. And no, this is not static typing.
Kind regards
robert
Yes, there must be an exception of some kind if the parameter is
inappropriate. The question is whether to explicitly check the type of
the parameter and throw a nicer exception, or to explicitly *not* check
the type of the parameter and let the exception happen where it may
(i.e. when a needed method does not exist).
Arguments can be made for both sides, but which is considered the "best
practice" for Ruby development? The Ruby Standard Library suggests it
is the former, but the article I referenced above suggests it is the
latter.
The way I've always looked at it is that the Ruby core and standard
library do a certain number of things along these lines that are
necessary for bootstrapping the basic classes into existence and
dealing with their relations, but that aren't necessarily what you'd
do normally when using those classes. You get a lot more "type"
errors (most of which are actually class errors) from the built-ins
than from most other code.
The main disadvantages of testing for class/module ancestry are:
1. it doesn't actually guarantee an object's behavior;
2. it discourages thinking about more flexible ways of programming.
I think that in the case of some of the standard and core classes,
these concerns don't loom as large as they might in our programs. At
the same time, there's no particular reason for those classes *not* to
be more duck-type oriented, if that can be done without introducing
any problems.