On Mon, Oct 8, 2018 at 11:11 PM Steven D'Aprano firstname.lastname@example.org wrote:
On Mon, Oct 08, 2018 at 09:32:23PM +1100, Chris Angelico wrote:
On Mon, Oct 8, 2018 at 9:26 PM Steven D'Aprano email@example.com wrote:
In other words, you change the *public interface* of your functions all the time? How do you not have massive breakage all the time?
I can't comment about Marko's actual use-case, but *in general* contracts are aimed at application *internal* interfaces, not so much library *public* interfaces.
Yet we keep having use-cases shown to us involving one person with one module, and another person with another module, and the interaction between the two.
Do we? I haven't noticed anything that matches that description, although I admit I haven't read every single post in these threads religiously.
On Mon, Oct 8, 2018 at 5:11 PM Marko Ristin-Kaufmann firstname.lastname@example.org wrote:
Alice tests her package A with some test data D_A. Now assume Betty did not write any contracts for her package B. When Alice tests her package, she is actually making an integration test. While she controls the inputs to B from A, she can only observe the results from B, but not whether they are correct by coincidence or B did its job correctly. Let's denote D'_B the data that is given to B from her original test data D_A during Alice's integration testing.
If you're regularly changing your function contracts, such that you need to continually test in case something in the other package changed, then yes, that's exactly what I'm talking about.
I'm tired of debating this. Have fun. If you love contracts so much, marry them. I'm not interested in using them, because nothing in any of these threads has shown me any good use-cases that aren't just highlighting bad coding practices.