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

Feature: CondExprAndOr (|| and && signs) #20

Closed
WeeskyBDW opened this issue Jul 29, 2020 · 14 comments
Closed

Feature: CondExprAndOr (|| and && signs) #20

WeeskyBDW opened this issue Jul 29, 2020 · 14 comments

Comments

@WeeskyBDW
Copy link
Contributor

WeeskyBDW commented Jul 29, 2020

Type of Feature
Conditional Expression

Name
CondExprAndOr

Explanations
a conditional expression wich allow us to use || (or) and && (and) in a condition to make multiple conditions

Exemples
if {e} == 1 && {f} == 2 (if e is equal to 1 and f is equal to 2)
if {e} == 1 || {f} == 2 (if e is equal to 1 or f is equal to 2)

@Romitou

This comment has been minimized.

@Olyno
Copy link
Contributor

Olyno commented Jul 29, 2020

I think it would be sufficient to add these comparators as aliases to the existing ones.

What do you mean, which existing ones?

@Romitou
Copy link
Contributor

Romitou commented Jul 29, 2020

Oops, sorry! I read too fast.
So yes, that would be good!

@FranKusmiruk
Copy link

Considering the intent of Skript, I am partially against this kind of expressions. Sure, it's useful for power users but in the end, it kinda defeats the purpose of Skript being english-like. The conditions you've used as example can be a single condition in old Skript like this:

if {e} is between 1 and 2:

if {e} is 1 or 2:

And it's pretty much the same case for the big majority of conditions.

@noftaly
Copy link

noftaly commented Jul 29, 2020

The conditions you've used as example can be a single condition in old Skript like this

No it can't because they are two different variables (in his example).

if {e} is 1 and {f} is 2: would be the correct thing, and this is not currently possible in Skript afaik, and would be a really good addition!

@FranKusmiruk
Copy link

The conditions you've used as example can be a single condition in old Skript like this

No it can't because they are two different variables (in his example).

if {e} is 1 and {f} is 2: would be the correct thing, and this is not currently possible in Skript afaik, and would be a really good addition!

it is possible, it is just a bit wonky:

if {e} and {f} are 1 and 2:

But in the end, I am not against being able to use multiple conditions at once (as long as it isn't abused to the point it doesn't have any kind of english grammar resemblance), I am definitely against it using the mentioned symbols for it though

@Olyno
Copy link
Contributor

Olyno commented Jul 29, 2020

Indeed Skript is english based, but as you probably saw, recently, Skript introduced this kind of shortcuts (e.g Default Value).
Like you already told me, the language evolves with a lot of new things. There is no reason why we could not add this shortcut as user's choice, but still have or and and words.

I think we can add both syntaxes, and user make the choice of which one he prefers. It doesn't change all the code to implement that, and can make happy a lot of developers.

@FranKusmiruk
Copy link

Indeed Skript is english based, but as you probably saw, recently, Skript introduced this kind of shortcuts (e.g Default Value).
Like you already told me, the language evolves with a lot of new things. There is no reason why we could not add this shortcut as user's choice, but still have or and and words.

At the time, I didn't really think about it but I would have definitely be against the ? pattern considering what I said above. This project doesn't have to go for the same path Skript went, I wouldn't say they were errors but at least from what I can see, it could definitely have been different, in a good way.

I think we can add both syntaxes, and user make the choice of which one he prefers. It doesn't change all the code to implement that, and can make happy a lot of developers.

Exactly, developers. Skript isn't designed for your common developer, it is designed for people who don't have a lot of knowledge in the programming world in general, and that's ultimately what decisions should be based off. Just to make things clear, I am not against the feature itself, I am against the suggested pattern.

@Syst3ms
Copy link
Contributor

Syst3ms commented Jul 30, 2020

After thinking about it, perhaps adding all of these programmer-friendly, beginner-unfriendly abbreviations isn't the best idea. I might roll back some of the syntaxes with these kinds of abbreviations to only keep the more english ones.

However, there remains one issue with all this : or in lists conflicts with or as a boolean operator. I'd like any input on this particular problem.

@Olyno
Copy link
Contributor

Olyno commented Jul 30, 2020

After thinking about it, perhaps adding all of these programmer-friendly, beginner-unfriendly abbreviations isn't the best idea. I might roll back some of the syntaxes with these kinds of abbreviations to only keep the more english ones.

Maybe should be good to have a plan of what skript-three should look like to avoid some confusion with an official Roadmap too. This plan and Roadmap could be an issue pinned, or a .md file in the project directly. A contribution guide could be good too to add to structure the project. I could write one if needed and make a pull request about it.

However, there remains one issue with all this : or in lists conflicts with or as a boolean operator. I'd like any input on this particular problem.

Maybe move the discuss about it directly in #23 because it's no longer related to this issue.

@FranKusmiruk
Copy link

I actually do not agree on this. Skript-parser is not made with the intend to be a copy of Skript. It’s made to be a useful and GOOD one.

skript-parser is literally that, a parser for Skript. Skript, by definition, is a language that strongly embraces the concept of being English alike, becoming easily understandable even for those outside of the programming world. If it goes in a different path, it may as well be called something else. Furthermore, the language stops making sense when you start adding syntax like this, considering you could just go with python or another very high-level language.

The current parser already has some ‘non-english’ syntax like expr ? val : val. I think both implementations should be added as long as it doesn’t conquer with other syntax (which can be evaded using the priority system).

I already addressed this point, so I'll just quote myself:

At the time, I didn't really think about it but I would have definitely be against the ? pattern considering what I said above. This project doesn't have to go for the same path Skript went, I wouldn't say they were errors but at least from what I can see, it could definitely have been different, in a good way.

@Olyno
Copy link
Contributor

Olyno commented Sep 3, 2020

Implemented in the pull request #22. I close this issue.

@Olyno Olyno closed this as completed Sep 3, 2020
@Olyno
Copy link
Contributor

Olyno commented Oct 1, 2020

Why dont use xor and xand logic operators ?

Please look at the pull request, and look at the discuss in this issue.

@WeeskyBDW
Copy link
Contributor Author

WeeskyBDW commented Oct 1, 2020

Mb x)

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

No branches or pull requests

6 participants