4 ms·
Yes, I agree. I probably should've been more clear that when I said "behavior," I meant "behavior observable by the caller." Going back to the original article
by nimih 3y ago
Yes, I agree. I probably should've been more clear that when I said "behavior," I meant "behavior observable by the caller."
Going back to the original article, it seems reasonable to me that the following qualifies as such a user-observable change:
foo(null) # throws InvalidArgumentException
updated_foo(null) # the same as foo(0)
- Tcepsa 3y agoThank you for the clarification; that's a much more compelling argument, and I think I am inclined to agree. I believe, however, that that is not what Hickey is saying. He's not saying "previously you could pass null and it would throw an exception, and now you can pass null and it won't throw an exception". He's saying "Previously if you tried to pass null you'd get a compiler error, but then I figured out that the method as written can handle nulls, so I changed the type signature to allow null to be passed in without the compiler throwing an error about it. See the updated documentation to understand what it does if you pass in a null value." This isn't a breaking change because up until that point any code that was written to use that method already wasn't passing null (because it couldn't, because it wouldn't compile). The method's behavior hasn't changed, just its type signature, and so for any of the arguments that the existing code might possibly pass to it, it will still handle all of those exactly the same as it would have before (because, again, the implementation did not change). Therefore, it is not a breaking change.