From: Thien Vuong Date: 2003-11-19T15:47:17+09:00 Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) dblack@wobblini.net wrote: > > > 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. > Uh... If we're getting there the equivalent argument would be "respond_to?" would not tell you anything except that it respond to "respond_to?" :). Unless we agree on some basic contract that a method need to satisfy (knowing that it could be changed - mind you), it is pointless to go one way or another. > >>- 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 Do you mean because we tend to call respond_to? closer to usage point than kind_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.) > I could see that one could reasonably take that position in any particular design. The software structure is created by specification and design to attain specific requirements - and one could "choose" to limit the flexibility/power to obtain other more desirable goals for that piece of software - ie. performance, contract guarantee, \ no runtime error, etc... Flexibility and power, as much as I like it, almost never enters in an application requirements :). That is not to say that other ways is necessarily wrong - but it certainly is within that "chosen" framework. > 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). > I'm trying. But I find existing Ruby facility as good enough - until Matz amazes us again with new features :). Regards