From: dblack@... Date: 2003-11-19T06:07:13+09:00 Subject: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) Hi -- On Tue, 18 Nov 2003, Thien Vuong wrote: > dblack@wobblini.net wrote: > > > > The system you're describing -- one-to-one, immutable mapping of > > methods in a class with methods of which that class's instances are > > capable -- is only proven and established in languages where it's > > enforced, which don't include Ruby. What you're saying is sort of > > like saying: using a keyboard to generate musical notes is proven and > > established, so let's add keyboards to violins. (Actually it's more > > like saying: let's play the violin by using its keyboard; to which I > > say: what keyboard? :-) > > > > I don't think I'm describing a one-to-one, immutable methods ... > I'm aware that the class could be extended/modified, just as > individual method could be modified too. I'm only searching for a way > to ensure the needed behaviour are implemented - "when such a need > arise". Class name checking doesn't ensure needed behavior. Actually, let me say first that while I have a lot to say here, I don't mean to single out your post or pounce on your wording; what's happening is that I'm growing concerned because it seems that we're going through a flurry of popularity of #is_a?-based checks which pretend to be type checks but are not (some done raw and some done using wrappers like "StrongTyping", all of which are actually checking class and module names rather than type). I fear that this is starting to have the cumulative effect of truncating people's understanding of objects, dynamism, and type in Ruby. I'd like to truncate the truncation :-) When one acts as if class name is an indicator of interface, one is in effect saying to the object: "You are an ABC, and on the basis of knowing only this, I am able to predict your behavior!" In other words, what's going on in these class-checking practices is not type checking or strong typing but, in fact, _stereotyping_: that is, the belief that one can infer what an object can and will do from what it "is". Needless to say (I hope), I mean this on a very local level; I do not mean that people who habitually perform these specious "type" checks are stereotyped in their social thinking. In fact, quite the opposite: I'm going on the assumption that we all recognize the frailty and brittleness of social stereotyping, and I'm suggesting that stereotyping Ruby objects -- inferring the "can" from the "is" -- is, in its much smaller domain, equally frail and brittle. > From my limited understanding, there are 2 types of checking that could > be used: respond_to? (duck-typing?) and kind_of? By Ruby dynamism, > none of the current method could guarantee the behaviour. So we're > have some choices: "Duck typing" is not essentially linked to any particular method; specifically, it is not essentially about calling respond_to? Ruby gives you duck-typed objects -- that is (in my paraphrase), objects whose types are inferential, consisting of the sum of their behaviors at a given point in program execution. You can deal with these duck-typed objects in various ways, of which respond_to? is one. > - Respond_to? is fine. It works for a large class of problems where one > or 2 methods are good enough to define the behaviour. In fact, for > those, a type/class contortion is overkill and having this capability > on Ruby is great. > - kind_of?, which to me, is a combination of respond_to? with the > expected behaviour of the class. It comes at a cost that the object > does need to be in the correct class hiearchy. kind_of? has no connection to respond_to? except that you learn whether or not the object responds to "kind_of?" :-) So the cost you pay -- that the response to kind_of? has to pass some test of name-membership -- in most cases gets you little or nothing. > - A very flexible behaviour model based on respond_to? This is great, > but requires extra coding, could be buggy, and have > performance impact. > > None of the methods, however, would guarantee behaviour - It more or > less a higher/lower degree of assurance :). Absolutely -- and respond_to? gets you a lot closer than kind_of? since it tells you what's going on as close to the moment of method-calling as possible. (One can take the position, as some have in earlier discussions of this, that code which fails to supply objects whose types are represented by their classes -- and which therefore might benefit from the use of respond_to? -- is by definition 'broken'; but this is of course a circular argument, and one which simply tosses a great deal of Ruby's power and flexibility into the trash for no good reason.) > Assumes, that a design has to do this checking > at some point, a reasonable implementation would have to be a > combination of system design to control the checking points, a set of > checkin of type (either respond_to or kind_of), and a set of > decent test cases. > > > > These things aren't at war with each other; it's a dynamic, > > object-oriented language. I'd advise against looking at the dynamism > > of Ruby objects as "extra". It's present from the ground up, and goes > > absolutely straight to the heart of the "type != class" principle in > > Ruby. > > > Kind of agree - type is not class. Just as class != static - it's only > a set of qualified behaviour. > > But it does not have to be different either. As I don't know of a > "generally" better way to check for type/behaviour (when needed) - > it should be part of the design toolset until there is a better one :). > I'll be glad to drop it all if I know a good way - really. It doesn't have to be different, but it *does* have to be -- will always be -- *potentially* different, because this is Ruby :-) And, when you get right down to it why not? People sometimes make it sound like Ruby objects' interfaces were made mutable to tempt us, and our ability to act like they're not mutable is a test of our strength of character. I just don't see the point. Anyway, I don't know that there is one way to check type -- that is, there's no one way to guarantee correct behavior on the part of Ruby objects. (I'm interested in what Matz is thinking about for 2.0, but it's only been mentioned in a very preliminary way.) Checking the class name with is_a? or "StrongTyping" doesn't tell you anything about type or behavior, unless you constrain your programming habits as described above (and never use external libraries or code written by people who choose to embrace the dynamism of Ruby objects). I would say, keep exploring, think of ways to design your code for the kind of scaleability where, as far as possible, objects are asked to do things and can do them (or take appropriate action where they can't). David -- David Alan Black home: dblack@wobblini.net # New email address work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav