Hi -- On Tue, 25 Jul 2006, 7rans wrote: > > dblack / wobblini.net wrote: > >> I've always thought that Dave Thomas coined it, and that it then >> caught on (including outside of Ruby). Either way -- I think that >> using "duck" in method and class names dilutes the meaning of "duck >> typing", and also does a disservice to the stuff people are writing, >> some of which may be quite interesting. When I see these >> prototype-style libraries named "duck" this and that, I'm just aware >> of the fact that duck typing isn't something one can implement in >> code, and that therefore the point of this code is being obscured >> rather than revealed by the naming. > > This argument has been made before, notably by you, and it simply does > not hold-up to scrutiny. First of all, how can a programming language > do anything that does not arise from implementation. That's completely > contradictory. But I'll take that to be a misstatement, and you > actually just mean that duck-typing is not something you explicitly > declare, but rather is an implicit occurance of not imposing type > restrictions on method arguments. No misstatement: Duck typing isn't something one can implement in code. If you say, "So-and-so codes in an elegant way", that doesn't mean that the next step is to create an ElegantWay module. Duck typing, as Dave Thomas has put it, is a way of thinking about programming in Ruby. You may write a module that people who think that way find useful, but that doesn't mean that it should be called DuckTyping. You cannot implement a way of thinking, per se, in code. > However you are wrong to think that > there is no imposition being made at all. When an object is the > receiver of a message to which it does not respond, it readily object > with a resulting NoMethodError. So disavowing #respond_to? as > antithetical to duck-typing is simply delusional. Explicit is just the > otherside of the implicit coin. Defining a set of methods based on a > conformity to a "duck type" is therefore not contrary to the original > coinage, but in reality furthers it by taking into account all side. > Which is what I was saying with my original post, that the "duck" > concept as currently implemented may yet be only half turned. It would > then be clear that your hold to this specific idea of the > inexpressibility of a duck type is effective only at stymieing > innovation in the area. I seem to have hit some kind of nerve here. (To parapharse your earlier comment: I'll take your characterization of me as "delusional" as a misstatement :-) But reread what I wrote originally. It's got nothing to do with stymying innovation. I'm just suggesting that hitching all of this experimentation to the "duck/quack" wagon, when it comes to method and class and module names, does a disservice to both the duck typing concept (which isn't about writing modules called Duck) and to the code you're writing (the possible usefulness of which is obscured by the peculiar names). 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