-
Notifications
You must be signed in to change notification settings - Fork 8
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 switch function #7
base: master
Are you sure you want to change the base?
Conversation
Yeah what about multiple cases using the same branch? like switch(xxxx) {
case a:
case b:
blah();
break;
default:
dude(pls, why);
break;
} |
There's a few ways to do it, it could be {switch:{args}|cases:[a,b]|bar|baz|thing|default:abc} Or maybe something like {switchregex:{args}|cases:(a|b)|bar|baz|thing|default:abc} To be honest the syntax can be anything to fit here, but I wanted to follow how the original syntax for the language looked. Do you have a suggesetion? |
I'm not super concerned with fallthrough, one thing that I don't think is clear from the syntax though is whether:
is
or
I'm trying to think of syntax improvements, but I'm not quite sure which direction to go. Also, I think a "closest" version of switch would be very useful, where instead of looking for an exact case name and using the default if not found, it used whichever case name was the "closest," (based on some calculation), or default if nothing matched within a certain threshhold. This would probably use nearly identical syntax, albeit different code internally. |
This was brought up because we were running out of space doing if statements and the syntax are like that just to be able to save more space. It does the first option, where the thing to execute is immediately after the case, like how a common switch works. I was thinking of just using the statements from if, but I think it should be something that's applied as a whole to make it easier, as per case matching of the modifier would be too messy. {switch:{args}|~|
test|hello|
foo|bar|
baz|plum|
default
}``` |
Case-insensitive matching can be done like this (also {switch:{lower:{args}}|cases:case1|val|case2|val2|default:def} I definitely want to see this added, I just want to make sure that it's set up in a way that's consistent with what exists, and will be able to be expanded upon later. Also, while not quite as concise as this new switch statement, you can currently do something like: {set:case1|val1}{set:case2|val2}{set:case3|val3}{get:{args}} which might be a bit more-readable than nested if-statements, albeit more difficult to do default values. |
Well anyways, with this it's good enough, I don't think we need to setup the switch in a way we could use the if statements, I think I should implement an {switch:true|{eval:{args}|>|90}|Excellent!|{eval:{args}|>|50}|Good|default:Bad}``` |
I'm reading the AppVeyor log and can't figure out what's failing the build |
|
||
|
||
// performs a conditional and outputs true/false | ||
new Method("eval", (env, in) -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this isn't solving the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? I think case fallthrough can be solved by the eval method, I just need one more function, which would be {logic:&|{eval}|{eval}}
Anything else than this differs too much from the original language, which I wanted to replicate as much as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eval might be possible to exploit. Thats just why... you know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not an actual !eval from anywhere. It's the same evaluator that {if}
uses. Maybe take a look at the code first? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually don't think eval should be part of this PR; it doesn't seem related to switch statements, and I'd rather it be called something like boolean
or conditional
, and be added at the same time as logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a fair point. I'll move it to another PR perhaps.
If a multiple case scenario was really needed, I feel like arrays could solve the issue much better. {switch:{args}|cases:
["foo","bar"]|result1|
baz|result2|
default:bass
} But this sort of thing (arrays) aren't implemented yet, so I will come back to it once they're done. {switch:true|cases:
{bool:{replaceregex:(foo|bar)|with:true|in:{args}}|=|true}}|result1|
{bool:{args}|=|baz}|result2|
default:bass
} |
This adds a switch function to the JagTag.
The default is required, and the cases need to be the same amount, otherwise, the default is returned if the number of cases and values return are not equal.