From: Dumaiu <Dymaio@...>
Date: 2006-07-26T05:55:11+09:00
Subject: Re: I'll have the duck!

dblack@wobblini.net wrote:
> Hi --
>
> On Tue, 25 Jul 2006, Dumaiu wrote:
>
> > I'm not sure what the best place for this is; sorry.  The following are
> > my views:
> > 	What we know as 'duck typing' is not really a programming paradigm,
> > but a set practices as Mr. Black says--merely the "yin" end of the
> > type-checking continuum.  I first learned about it, although of course
> > not by that name, from studying C++ templates, where also the
> > prevailing wisdom is that you shouldn't assume anything more about your
> > library's client's code than is absolutely necessary.  The 'duck
> > typing' moniker that marks it as a novelty is most useful against the
> > background of static languages, where type-checking helps prevent
> > runtime errors.  For Ruby, where *every* error is runtime, duck typing
> > is the raw form of its behavior, and should be recognized as quickly as
> > possible, because it isn't always good.  At its utmost, duck typing is
> > the total absence of validation.  You are saying that nothing about
> > your client's program is worth trying to predict, that 'if it works, it
> > works,' and if it doesn't, he'll know because it just blew up.
>
> True, though that's partly why test-driven development is so big among
> Rubyists.
>

*Whew!*   That's a relief.

>
> At some point in the past I think I posited a distinction between
> "soft duck typing" and "hard duck typing" :-)  Very much along the
> lines you're describing: soft duck typing involves the "extra" layer
> of respond_to? and hard duck typing doesn't.  respond_to? is certainly
> a sensible precaution to take, in many cases, and one that operates in
> the orbit of the object itself (as opposed to kind_of?).
>
> (I'm not quite sure what you mean about include?....)
>

I meant Module#include?(), as the mixin-checking counterpart to
inheritance-checking.

>
> It seems to me (though I don't know any of the prototyped languages in
> any depth) that Ruby indeed gives you both: a per-object universe, and
> a class system.  Ultimately, the former sort of "wins", in the sense
> that classes are objects and so on... but actually I think the two are
> in a nice balance.
>

I agree.  Classes and modules complement each other well, and an
immutable object prototype kept around only for cloning really isn't
very different from a class definition.  I like the support for
multiple approaches.

> > 	Personally, I feel that Ruby needs more, rather than less, type
> > safety, to balance its natural inclination otherwise and because no
> > amount of 'duck typing' disaffirms that erroneous behavior is best
> > caught as soon as possible.
>
> True -- but it may have to do with how one defines "possible" :-)  One
> could say that no amount of early checking can change the fact that
> the only absolute way to know what sending a message to an object will
> do is to send the message to the object.  In practice, one settles for
> non-absolute ways, not only because they tend to work but because
> they're all that's available.  But I'm always fascinated by the
> singularity of a Ruby method call: there's nothing else around it that
> really, absolutely pertains to it.
>

The atomicity of a Ruby call makes for a nice, visceral experience,
doesn't it?  :-D  I'm glad you pinpointed the definition of 'possible,'
because therein, as they say, lies the rub, and as it turns out I have
feelings about that, too.  I'd advocate the use of respond_to?(),
because, as you say, it seems a 'sensible precaution.'  I would
relegate method_missing() to the court of last resort and absolve
library designers from worrying about it.  Because it's so powerful,
its use can't be predicted or guaranteed to operate properly; and if,
as I believe, every Best Practice should have a back door available for
exigency, method_missing() can never be a Best Practice, because it is
the ultimate back door.
	I think you understood my point, though.  Too much duck typing and you
have to throw up your hands in surrender.

> > But I don't think anyone would advocate a
> > return to rigid inheritance checking, which realization the deprecation
> > of type() notably indicates.
>
> Actually the deprecation of type, I believe, has a different cause.
> As I understand it, in early Rubies there were problems parsing:
> obj.class, so a name other than "class" had to be used for that
> method.  Now that obj.class can be parsed, "type" is no longer needed
> -- and, as Matz has said, it's problematic because it discourages duck
> typing.
> 

Oh, really?  Thanks for setting me straight.