On Wednesday, 3 September 2003 at 4:22:56 +0900, Hal Fulton wrote: > james_b wrote: > > Sean O'Dell wrote: > > " > > > >> > >> So, in my line of thinking: me.eat(food) > >> "Hello world".print to me equates to: food.eat. > >> > >> I eat. Food doesn't eat. $stdout prints. Strings don't print. > > > > > > Isn't this begging the question? > > > > The argument seems to be, "print has been defined for $stdout, not > > string; since strings don't have 'print', string.print would not be not > > correct." > > That's not what he's saying at all. > > He's saying that conceptually the print method *should* > belong where it in fact is; that, conceptually speaking, > he does not think of print as an operation belonging to > a string. And I agree. > It seems that the alternative methodology would have too many code updates to be practical. In other words, everytime you need something new done to the data type, you would have to modify its class. For example, we have several data formats. These data formats are fixed and don't change. So, we write a class that parses them (with unit tests) and check it into CVS and don't change it. Then, about once a Qtr, someone comes up with an alternative way to use the data and wants it in a slightly different format. We handle this by writing dropin filters that support the new format/functionality. The filters utilize the original class to extract the data. If we go the path of writing #to_whatever methods for the original class, then the original class keeps growing (which can cause load time issues) and keeps changing. Theoretically it doesn't change, but whenever you have multiple programmers with their fingers in the pie, your bound to get a dirty pie at some point. In addition, it makes for easy debugging. I'm not an expert, but our method seems to be working. The other approach seems dogmatic, and I wonder how pragmatic that is. $0.02 -- Jim Freeze ---------- Cat, n.: Lapwarmer with built-in buzzer.