> This will work for basically any possible value/type of foo, assuming foo supports .toString(). It will work for NaN, it will work for infinity, it will work

> This will work for basically any possible value/type of foo, assuming foo supports .toString(). It will work for NaN, it will work for infinity, it will work if the value is already a string. A) the example above was explicitly for int -> double, so the fact that it the path through .toString will work for other types is a benefit we won’t get but which has a cost we’ll have to pay regardless. B) I find it hard to believe that the Double class doesn’t my have a method you could call which will convert an int and catch NaN, Null, and MaxInteger. > In most places that's probably a sane call. Is it always the right call? Just as you’d bet that the hash implemention will become slower, I bet you that only 1 in a million people (if that) would write the Double code we’re talking about as the result of thoughtful consideration. > optimize when optimizing becomes important, because something is slow and it sucks. Until then... slow is smooth and smooth is fast. Slow is smooth assumes that the slow path you pick is sane. There’s also a big difference between having to write code that needs optimization, and writing less code to do a job faster.