From: "David A. Black" Date: 2005-08-18T12:39:49+09:00 Subject: Re: Prototype-based / Ruby question Hi -- On Thu, 18 Aug 2005, Eric Mahurin wrote: >>> Take a look at the original definition of duck-typing given >> by >>> Dave Thomas. Here is the example he gave: >>> >>> | When I write >>> | >>> | fred << "dog" >>> | >>> | in Ruby, I don't care whether fred is a String, a File, >> or an >>> >>> | Array >>> >>> In this context, the "duck type" of fred is something that >>> reponds to <<(aString). >>> >>> By your definition of "type" being "the sum of all of its >>> capabilities", you'd have to pick what "type" fred is - >>> String-like, File-like, or Array-like. >> >> On the contrary: I *don't* have to pick or describe or find >> synonyms for what it is. That's the point: the type is what's >> there. I don't even have to name it. > > From what you said above, I don't see any debate over how I > defined "duck type" (other than the name). I only see you > clarifying what you meant by "type". I still don't see a > concrete definition of yours, but it sounds like you might mean > the same as what I said for "duck type". But, when you say > "type" is "the sum of all of its capabilities" and "an > object's type can change and evolve during runtime" this says > to me your "type" is associated with the object itself and not > how the object is used. All that really matters regarding > "type" in my opinion is how an object is used. What a > particular object's entire capabilities and the fact that they > can change over time is orthongonal. It sounds like you think I mean you should send all possible messages to an object simultaneously, or something bizarre like that. Obviously any given use of an object does not recapitulate or encapsulate its entire type, if "type" is defined as the object's capabilities. At the same time, it's not a good idea to use an object in ways its type does not support -- so in that sense, type and how an object is used are very tightly connected. (Unless you're depending heavily on method_missing, of course.) > I'm not sure why you don't like the term "duck type". It is > directly associated with the term "duck typing" and is quite > clear in that context. I don't understand the need to talk > about/document an abstract "type" beyond the context of "duck > typing". Can you think of anything else? I don't like the term "duck type" partly because I consider "type" to be adequate (since type in Ruby is already a matter of dynamic message-recognition capabilities, rather than class membership), and partly because I think the word "duck" sometimes gets used so much and spread so thin, as a kind of general code-word for anything connected with dynamic typing, that the original sense of "duck typing" gets diluted and obscured, which I think is too bad. >> I personally wouldn't say "anything IO-like" (nor "O-like", though >> that might be closer :-) but rather: anything that responds to >> "write". That's *all* that matters. "IO-like" is a secondary >> concept, built on top of that. Let's say someone said: "no, it's >> not IO-like; I reject that." That person could still send "write" >> to fred, as much as you can. > > My point was that if you document your method to take an > IO-like object (which I thought was your way - sum of the > capabilities of an object), you have the freedom to use any of > the IO methods. I think I may see the problem here: perhaps you think I meant "summary of the capabilities of an object"? I can't think how else these notions like "IO-like object" have crept into the discussion. You seem to think I meant I want to slap specific, sort of pseudo-type labels on objects (IO-like, String-like, etc.), when what I've been trying to say is more or less the opposite of that -- namely, that the "type" of a Ruby object really cannot be labeled or summarized in this kind of way, because it is only defined by what it actually is at a given moment. In fact, the tautology of type renders it close to useless as a concept in Ruby; but in a pleasant way, I find. > If initially the method is implemented using > <<, it may work with anything that has the << method now, but > you run the risk of something breaking if the implementation > changes to use different or additional methods. If you > document a method like this, you give the method implementation > freedom to use a wide range of methods, but limit the caller to > objects that implement that entire interface. Why wouldn't you just say: "the argument to this method has to respond to <<" ? > Of course that is not the duck-typing or ruby way. The > duck-typing way is to document what capabilities you want/need > from an argument and that's it. This gives more freedom to the > caller and less to the method implementation. I would just call it "documenting a method" :-) But I'm not the duck police; you can use it any way you see fit. Certainly documenting the capabilities you need from an argument sounds like a good way to go about documentation. Objects whose type comports with the stated needs can then be used as arguments to that method. David -- David A. Black dblack@wobblini.net