Austin Ziegler
11/19/2003 6:00:00 AM
On Wed, 19 Nov 2003 06:07:13 +0900, dblack@wobblini.net wrote:
> On Tue, 18 Nov 2003, Thien Vuong wrote:
>> dblack@wobblini.net wrote:
> Class name checking doesn't ensure needed behavior. [...]
It certainly doesn't. That doesn't mean that there aren't times when
name/ancestry checking isn't useful. Or that "publishing" a method's
signature isn't (at times) useful. Note: I'm not changing my
position in this debate -- I still think that, based on my last two
years of experience with Ruby, ancestry checking is of extremely
limited utility.
The main place that I use ancestry checking at this point is when
dealing with Ruby's built-in types -- Hash, String, and Array -- and
then only when I need to distinguish between types that have
identical method names but subtly differing semantics (e.g.,
Hash#each and Array#each). (The other place that I use it is when I
have a custom type that I absolutely want to be used. See Ruwiki and
Ruwiki::Config for an example.)
> what's happening is that I'm growing concerned because it seems
> that we're going through a flurry of popularity of #is_a?-based
> checks which pretend to be type checks but are not [...]
In some ways, this is a good thing -- it generally means that we
have new faces coming in :)
> In other words, what's going on in these class-checking practices
> is not type checking or strong typing but, in fact,
> _stereotyping_: that is, the belief that one can infer what an
> object can and will do from what it "is".
I like this term. A lot.
[...]
One of the things that I'd like to see is perhaps a change to
#respond_to? so that it's like this:
class Object
alias_method :orig_respond_to?, :respond_to?
def respond_to?(symbol, arity = nil)
if arity.nil?
orig_respond_to? symbol
else
(orig_respond_to? symbol) && (method(symbol).arity == arity)
end
end
end
It won't help in cases as was posted (e.g., accepts one argument of
varying types that you may want to behave differently), but I think
that Ara Howard's recommended technique in [ruby-talk:85479] is
probably better in the specific posted case.
-austin
--
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 00.59.45