Kent Beck's book Smalltalk Best Practice Patterns covers this topic. It 
discusses two gotchas to the practice of adding conversion methods to 
the source class:

* No limit to number of methods to be added -- the protocol tends to 
grow and grow.

* It couples the source class to another class it wouldn't otherwise 
have knowledge of.

He says there should only be a conversion method when either the 1) 
source and destination classes have the same protocol, or 2) there's 
only one reasonable way to implement the conversion. His solution for 
conversions when neither of these conditions are true is to add a 
"Converter Constructor Method" on the destination class. So instead of 
string.as(Date), you'd say Date.from_string(string). This keeps the 
logic on Date, which is where it belongs.

As for the proposed code, what would a conversion table buy me? 
Wouldn't it just create a third place to put code that knows about my 
class? IMHO, the problem Ryan mentioned with NilClass#to_str not 
existing should be resolved in accordance with the POLS, but a 
conversion table smells like bad design to me. If I'm wrong, I'd like 
to better understand the benefits of the conversion table proposal.

On Tuesday, Jun 24, 2003, at 02:50 America/Chicago, Brian Candler wrote:

> It probably makes sense for most objects to have a 'printable' form of 
> their contents for display purposes - hence X.to_s - and also a 
> detailled printable version for debugging, hence X.inspect. But I 
> don't see any need for generic 'X to Y'.

-- 
John Platte
Principal Consultant, NIKA Consulting
http://nikaconsulting.com/