On 01/02/14 00:05, Vladimir Lushnikov wrote:
I disagree. With the same analogy, I could sell you a blunt knife -
you would use it as a letter opener, and then I would fix the bug. Now
you might actually cut yourself!
No. The correct analogy would be:
1) I create a recipe for a sharp knife. The first IMPLEMENTATION of
that recipe is a blunt knife, and so the IMPLEMENTATION is buggy.
2) You see that the IMPLEMENTATION is useful in its own right, and have
thus invented the concept of a letter opener.
3) You fork the code at that point, creating a new "Letter opener"
recipe from the buggy, "blunt knife" implementation of the "sharp knife"
recipe.
4) I fix my blunt knife implementation to create a sharp knife.
5) Everyone is happy.
I think this is a different concern. It should be up to the library
author what they deems as 'compatible'. It does not excuse the
consumers of the library to do their own testing that it produces the
results they want (a version number in any form is not a proof of
correctness).
Absolutely not. If people want to make their OWN, unpublished code in
compatible, then yes, that's their business. But as soon as they
release a library to others, they are making certain promises and
guarantees -- the library API's contract. They are saying that "we're
providing this code, which can do this, and will help with your code.
You can use it in your own projects, and save yourself time. What's
more, many people can use the same code, and save time/space
reimplementing the same things". If they make such an offer to help
others, then go back on it by breaking the code, it's simply
irresponsible: bad code maintenance. We should ABSOLUTELY discourage
that, if our goal is reliable, reusable, libraries which everyone can
use with some certainty.
--
Lee
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
