Hi -- On Sun, 6 Jun 2004, David Garamond wrote: > Okay, I'm trying to sum up this thread as well as test whether my > understanding of this whole typing issue in Ruby is more or less correct. > > --- > > 1. Ruby _has_ types. It's called classes. No; classes are called classes :-) In fact, Matz has deprecated the #type method (a synonym for class) to emphasize this distinction. (It only existed in the first place, I believe, because parsing the keyword "class" as a method name was impossible in early versions of Ruby.) Let me go at this from a slightly different angle: The behavior of Ruby objects (what messages they respond to, and how they respond) is bootstrapped *but not constrained* by their class. It is possible to put this fact in the category of "enough rope to shoot yourself in the foot" or whatever, and decide it's too powerful to take advantage of or take into account when designing a program. Personally, I see no reason to look at it that way; I like the idea of programming with, not in spite of, Ruby's design. But in any case, whatever interpretation one puts on it, the behavior of Ruby objects is not constrained by their class. OK, now that means that there is Something Other Than Its Class that characterizes and denotes the behavior of an object *more accurately* than the name of its class (or of any mixins) does. I'm not extrapolating any philosophy of programming from this; I'm just pointing it out. We need a way to refer to this thing. However, terms like "Something Other Than Its Class" or "An Object's Behavior At A Given Point" are obviously quite unwieldy. A much more concise term is "type". It makes sense, too: "type", as I understand it across languages, is expected to tell you what an object can do, and that's just what we're looking for. The fact that Matz has allowed an object's type to peel away from its class and chart its own course does not mean that the object does not have a type, in this sense of the term; and there is no reason not to simply refer to it that way. On the other hand, if we decide that type == class, then we're back where we started: we need a new term that refers to the Other-Than-Class thing. We can't just not refer to it; it's at the heart of Ruby's design. Moreover, if we rule out "type" and use it as a synonym for "class", it's going to create confusion, because two objects of the same class simply do not have to exhibit the same behaviors and when they don't, referring to them as having the same "type", on the basis of how they respond to the #class method, threatens to tie us in knots. I've kept duck typing out of my comments deliberately, because I wanted to spotlight some underlying concepts; but let me weave it in, or layer it on. The term "duck typing", as I understand it, is not itself a reference to Ruby's distinction between class and type but is, rather, an approach to Ruby programming that is built on top of a recognition of that distinction. Exactly where one draws the line may vary. (I've always liked to say, "Programmers don't do duck typing; Ruby does", but I think Dave Thomas actually had in mind something that programmers do with Ruby, and I'll go along with that :-). The important thing is that duck typing is not something imposed on Ruby from the outside; it's a follow-through on observations about the basic state of things as governed by Ruby's design. (See http://www.ruby-talk.org/78502 for Dave Thomas on duck typing.) This is important because sometimes people talk about duck typing as if, by *not* doing it, you were deciding that Ruby wasn't being as dynamic as it would be if you were doing it. But Ruby's type system is there all the time. Even calls to #kind_of? are, in the end, Ruby method calls, with all that that implies. David -- David A. Black dblack / wobblini.net