From: dblack@... Date: 2007-03-03T04:31:17+09:00 Subject: Re: Duck Typing Hash-Like Objects Hi -- On Sat, 3 Mar 2007, Rick DeNatale wrote: > On 3/1/07, dblack@wobblini.net wrote: >> A few years ago there were some interesting attempts to >> come up with a systematic way to determine an object's type, in the >> sense of its full profile and interface, at any given point in its >> life. The idea was to be able to get some kind of rich response from >> the object, well beyond what respond_to? and is_a? provide, in order >> to determine whether you'd gotten hold of the type of object you >> needed. I seem to recall it turned out to be very challenging, >> perhaps impossible, to come up with a complete system for this. I'm >> not sure if anyone is still working on it. But it's an interesting >> area. > > All of this is personal perspective of course, but my view of duck > typing is that it's really a question of the type of a variable rather > than on objects. In other words in my view variables have types which > are generated by their usage. Types in this view are like job > requirements. I'm not sure how that detaches it from the object, though, since variables are going to contain references to objects and messages are sent to objects rather than variables. Do you mean in terms of documentation? > So rather than talking about say an array type, to me duck typing is > talking about the type of a variable which is used in a certain way, > which might be somewhat idiosyncratic to the user. Some common such > types do exist, like a queue, a stack, a generalized collection (with > various requirements as to access, ordering etc.) given one of these, > or a more idiosyncratic type, several objects might work as the value > of the variable in question. I don't think duck typing has ever been about a checklist of common data structures or types (queue, stack, etc.), but more about just sending messages to objects without a lot of pre-message checking as to their class and ancestry and so forth. To me, the ultimate duck typing idiom is: def m(x) x << "string" end There's no checking, no probing the object -- you just ask it to do something, and deal with what happens. In the end, that's *always* how things are when writing Ruby. I've always seen "duck typing" as just a kind of embrace of the conditions under which every single line of Ruby is code is written anyway. > As an example, lets say I'm looking for something to use to drive a > nail. The obvious 'type' of thing for this job is a hammer, but a > heavy wrench, or a rock can also serve since the usage really just > requires a mass which can be conveniently accelerated so as to impart > inertia to that nail. If I don't have a hammer to hand, I can press > one of these other objects into service. All these nouns sound more like classes than types. Actually I don't think the type of a Ruby object can ever be named. It's circular: the type of an object is... the type of objects that are of this object's type :-) As soon as it gets noun-like it starts getting class-bound again. A duck-typing approach to hammering would be something like: def hammer(h,n) h.pound(n) end Everything's so in the moment. I know I have a somewhat Utopian view of Ruby types sometimes :-) But I really do find the implications rather enthralling. Noun-like-ness, by the way, has always seemed to me to be the Achilles' heel of the duck-typing analogy -- specifically, the part where it says: "... then it *is* a duck." That has a way of leading people back, quite literally, to is_a? -- as if the idea was that Duck was a class. (I know that's not what you're saying; I'm just reminded of this thought.) I've seen it rewritten (I can't remember whether it was by me or Florian Gross; one of us, I think) as: If it walks like a duck and quacks like a duck, then it walks like a duck and quacks like a duck. :-) > In this view of duck typing choosing an object is akin to hiring > someone, you make an initial assessment of whether the potential > employee has the requirements, and if s/he passes that sniff test, you > hire him/her and test that assessment over time. I think it's that very initial assessment that Gary was talking about: is there something -- not static typing, but some kind of dynamic, run-time mechanism -- that can provide pre-method-call semantics of an object? > These kind of types also can require much more than a simple list of > provided interfaces, they also typically rely to one degree or another > on the semantics of those interfaces, often including how the object's > observed behavior is affected by the SEQUENCE of calls. These types > of types are much harder to statically check. And they cause bugs in > either a statically or dynamically typed system. In my experience, > the kind of stupid bugs which are flushed out by a static type system > are a small percentage of the bugs which are caused by these semantic > mismatches. The question, though, is whether it's possible to come up with a semantically rich way of reflecting on the type of a Ruby object. It's not a static-vs.-dynamic thing; static checking wouldn't enter into it. It's more a question of having something that would do what people think class-checking does before they realize that it doesn't, if you see what I mean :-) It may well not be possible. David -- Q. What is THE Ruby book for Rails developers? A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black) (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf) Q. Where can I get Ruby/Rails on-site training, consulting, coaching? A. Ruby Power and Light, LLC (http://www.rubypal.com)