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.