From: "Jürgen Strobel" <strobel@...>
Date: 2006-08-03T00:01:50+09:00
Subject: Re: I'll have the duck!

--7qSK/uQB79J36Y4o
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 25, 2006 at 01:05:11PM +0900, 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.

No. That's not duck typing, that is shoddy programming.

You may have a rescue clause right after your doubtful code,
or somewhere else upwards in your call stack. Or it might be
guaranteed by application semantics (as opposed to static typeing)
that your object can handle the messages sent to it.

My take on duck typing:
- allows sending messages to objects without *prior* validations.
- breaks up dependencies on a strict class hierarchy by allowing to send
  any message to any object.

Neither of them requires that a program may blow up.

> 	Hmm.  I see where type-checking came from.  As far as Ruby best
> practices go, I think 'duck typing' just means using respond_to?() more
> than kind_of?() and include?().  If you really wanted to, dumping class
> use entirely and turning Ruby into a prototype-based language wouldn't
> be too hard: you'd use Object::new() only, define only singleton
> methods, and extend objects with clone(); and if you wanted to
> delegate, you'd keep an array of references of "parent" objects,
> Perl-style.

Sometimes it might be better to use #responds_to? early, and many
people will still consider this duck typing. It may be less "pure"
than handling NoMethodError, but it might be just the right tool
depending on your situation.

Even #kind_of? can have its merit in certain situations. I wouldn't
call code using it to rely on duck typing though, but that's not a bad
thing per se.

Prototype based languages are tangential to this, and need not be
drawn into this discussion here.

> 	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.  But I don't think anyone would advocate a
> return to rigid inheritance checking, which realization the deprecation
> of type() notably indicates.

By your argument, exceptions are bad too, because they catch errors
"late". And IMHO exception handling was one of the better points when
going from C to C++. Think of duck typing as yet another technique not
to litter your code with error checking, but still do it
somewhere/sometime. You do handle C++ exceptions too, do you, if not
neccessarily right next to throwing them?

I repeat: duck typing is not to produce bombing out code, but a new*
way to handle dynamic and flexible type validation "late", with the
objective to ease development and produce clean code.

* actually not. But many people coming from C++ or Java just don't know
prior OOP languages.

-J=FCrgen

--=20
 The box said it requires Windows 95 or better so I installed Linux

--7qSK/uQB79J36Y4o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQEVAwUBRNC+Wfy64gyiEfXtAQIirggAvq6P7gcE3//6aGHc7hPOr5w0LIWZIlrK
S5KavbxVqZIt+iC7laV9oliyPsigE25UFiW7cx/EYBYkPAohCJMB2iJ9j10bOng/
1mLeuTQzOmlxsdtXthAlfKUXCKB6qeebqs44AeJGtqJ3TovSL+oC7IiNfZMkhLxk
e4/B9rkqvMZ8TRgJErfJrGziE53iZcSKYBGfv4svK+oyTD4c0vNTzdFcMmal2vH7
4OwtoEwJa8jfeDqbON2ysk9apgcSOrywXe6piUzmLNjhEs4gK5dmT/KtJW7cpKGH
BamT/SFBgzpAkovYiQsG2+mEs05v0euhE9DwgGqQ3257s9Nvg/PcvA==
=REI3
-----END PGP SIGNATURE-----

--7qSK/uQB79J36Y4o--