Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "not" boolean operator #275

Merged
merged 7 commits into from
Jun 30, 2023

Conversation

andycoopcode
Copy link
Contributor

I've had difficulty expressing certain rules in a readable way without the ability to negate conditions.

For instance if I wanted to create a rule saying "trigger an event when there is not any condition which is true," I would instead have to express this as "trigger an event when all conditions are false." This means that I would have to write each condition as its logical negation, which potentially affects the readability of the condition.

These changes add in a new not boolean operator alongside all and any which negates the result of whatever single condition is nested inside it.

I believe this addresses issue #269.

@liquid36
Copy link

It's look nice! Very helpfull

@cgerikj
Copy link

cgerikj commented Sep 13, 2021

Hi, is there anything stopping this PR from being merged? I was just about to create an issue on this too and would find it very useful. 👍

@frebos88
Copy link

This would be a great addition!

@mnording
Copy link

Would love this feature!

@RobbeCl
Copy link

RobbeCl commented Sep 26, 2021

+1

@gnowakpoloniex
Copy link

We could really use this feature!!! +1

@StingyJack
Copy link

"trigger an event when there is not any condition which is true," I would instead have to express this as "trigger an event when all conditions are false."

I've read that three times now and the second one is significantly more understandable to me. More succinct, less complex, less mental effort required (all conditions must be false, rather than "not any condition which is true"). The first one may seem more readable and understandable to you currently, but thats not as important as it being readable by others (and you) later.

@andrewjleung
Copy link

Hi, I'm the original creator of this PR, just under a different account! 😄

@StingyJack I agree with you that the given example frames the need for a NOT operator poorly by doing so in the context of an any vs. all scenario. The intended value here is primarily in the following statement:

This means that I would have to write each condition as its logical negation, which potentially affects the readability of the condition.

Broadly speaking, being forced to manually negate a condition (without a NOT operator) which is more clearly expressed in either its positive/negative form, especially if it's deeply nested, can get messy.

@gnowakpoloniex
Copy link

@andrewjleung nice seeing you 😆 if this PR merges by next year, I'll buy you a beer!

@nileio
Copy link

nileio commented Feb 26, 2023

any update on this feature PR please ?

@chris-pardy chris-pardy self-assigned this Jun 29, 2023
@chris-pardy
Copy link
Collaborator

chris-pardy commented Jun 29, 2023

@andrewjleung I'm working with @CacheControl to help maintain this project now. I've been a bit out of pocket today but I hope to get a chance to review, test, and merge this PR before the weekend.

Thanks for putting this together, and sorry about the wait.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.