Ensure.That
Ensure.That copied to clipboard
danielwertheim
IsPositive, IsNegative, IsNotNegative, IsApproximately
In regards to Issue #71:
- Added IsPositive, IsNegative, IsNotNegative, IsApproximately methods and extensions
- Added 16 new unit tests to cover the new methods
Might want to look over https://math.stackexchange.com/questions/26705/is-zero-positive-or-negative for how to handle 0, evidently our assumptions might not hold for all application domains
How to handle the 0 is also what got me thinking of what would be the "preferred/expected" way.
@ndrwrbgs @dmarciano will it be to "expressive" to have e.g IsNonZeroPositive?
@danielwertheim I think it would be better to make it so that zero is not positive or negative by default (based on what I've ready in the article provided) and then have an optional parameter for specifying if zero should be considered positive, negative, or both. I can also update the exception method for when zero is the cause of the failed validation so that way it is clear to the user why it failed when they may have expected a zero to pass.
An enum is a lot better then a pure bool in this sense as it brings semantics. I'm guessing, most of the times, no one will use another value for it than the default. The idea with an "expressive" method name (that I suggested) is, that Ensure.That should be easy to understand (prefer not to go in and look at options, in this case the enum). I would be quite OK with only having the path of treating zero as zero (origin) and never count it into negative nor positive, just to keep the API simple and expressive. I mean, it could be solved using the support for IsLt/IsLte and IsGt/IsGte
What are your opinions about this? Adding these new members with no enum and not including zero. And then just document it in the XML comments for intellisense and additionally be more informative in the name of the member.
I can support the expressive method name option (programmers spend too much time trying to make short vague names so I'll always support longer ones :P). It supports fewer possible scenarios, but again this library is so easily extendable that supporting every scenario isn't necessary as long as those supported are clear. But if dmarc feels strongly I could support pushing for the enum route too :P
TLDR both support my use cases (>0, !<0) so I don't have any "skin" in the decision.
On Tue, Dec 10, 2019, 12:34 AM Daniel Wertheim [email protected] wrote:
An enum is a lot better then a pure bool in this sense as it brings semantics. I'm guessing, most of the times, no one will use another value for it than the default. The idea with an "expressive" method name (that I suggested) is, that Ensure.That should be easy to understand (prefer not to go in and look at options, in this case the enum). I would be quite OK with only having the path of treating zero as zero (origin) and never count it into negative nor positive, just to keep the API simple and expressive. I mean, it could be solved using the support for IsLt/IsLte and IsGt/IsGte
What are your opinions about this? Adding these new members with no enum and not including zero. And then just document it in the XML comments for intellisense and additionally be more informative in the name of the member.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/danielwertheim/Ensure.That/pull/125?email_source=notifications&email_token=ACSHCOTOAMA67G762IJS653QX5IA5A5CNFSM4JW62NZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGONAHA#issuecomment-563925020, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSHCORPOZXHGNHMYMZCTULQX5IA5ANCNFSM4JW62NZA .
@dmarciano do you want to merge with the latest master and get this into the next release?