4 ms·

Here's my experience with this sort of change: You have exactly one usage where you NEED the update. After deciding to make it you've identified a few other p

Here's my experience with this sort of change: You have exactly one usage where you NEED the update. After deciding to make it you've identified a few other places where you can use the updated code. The Right Way (TM) to make that change, then, is to make only the change to the result type in the first commit (along with the pattern matching necessary to ignore it), followed by a commit for each place that the updated result type can be usefully used. Change the code without changing the behavior: i.e. REFACTORING. Run the tests, verify you didn't break anything, then start writing tests for the behavior you wish to change, followed by changing that behavior. If you think you're at atoms you probably haven't seen strings.

yummyfajitas 11y ago
I suppose it could be done that way. But that seems like a lot of extra work, and you also lose the compilers help. Also, in my experience changes like this actually do involve lots of subtly broken code - think about it, anyone using fold on a network error is making a mistake (retrying the use of a closed connection). If you fix the behavior everyplace the compiler complains, you are guaranteed to resolve most issues (ignoring overloaded methods, e.g. getOrElse). If you use a toOption method on the union type to make a tiny atomic change, the compiler will no longer complain in all the places that mistakes are being made. I suppose an intermediate way might be to rename f to f_DEPRECATED, replace everywhere, and build the new method returning the right type. But in my experience its better just to bite the bullet and change everything.