egonSchiele
commented
6 years ago I like this idea! Answers:
a) is this likely to get merged if completed? Yes.
b) is this a reasonable approach? Yes.
c) any big pitfalls that I'm not thinking of *Here are some things that have caused issues in the past, I would construct a test case with a combination of these: pattern matching (especially with calls that cause contract failures) + contracts in modules instead of classes, with those modules being then included in a class + contracts inside a class << self block.
I like the support class, and I like the option to turn off decorators, invariants, and pattern matching selectively. I don't understand:
Similarly, I think it'd be valuable to have a feature that allows selective disabling of validation of contracts after having loaded them. (The idea being, it might permit running contracts in non-perf-sensitive codepaths in production or a fraction of prod requests)
Isn't this essentially the existing NO_CONTRACTS functionality?
indigoviolet
nathan-appere
We'd like to be able to turn off the pattern matching/method overloading behavior altogether -- it can lead to unpleasant surprises, and we don't want someone inadvertently writing code that relies on it in our environment.
Similarly, I think it'd be valuable to have a feature that allows selective disabling of validation of contracts after having loaded them. (The idea being, it might permit running contracts in non-perf-sensitive codepaths in production or a fraction of prod requests)
I've sketched a version of how I thought this might work to get some feedback from you about
a) is this likely to get merged if completed? b) is this a reasonable approach? c) any big pitfalls that I'm not thinking of
I haven't tested this very much at all, will proceed to do so if you think this is a good direction to pursue.