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. > 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?(). 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?....) > 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. 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. > 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. > 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. David -- http://www.rubypowerandlight.com => Ruby/Rails training & consultancy http://www.manning.com/black => RUBY FOR RAILS (reviewed on Slashdot, 7/12/2006!) http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log dblack / wobblini.net => me