mrdoob
Transpiler - Add Support for Switch Statements
Related issue: #30900, #30849
Description
Adds transpiler support for switches.
- [x] Generic Support
- [x] Default Statements
- [x] Extraneous edge cases which people would like to support
~~In lieu of having a custom block function for cases it might be better/possible to have case as one of the terminators in parseBlock/getGroupDelta. @sunag What do you think?~~ I've moved to the suggested approach, as the previous approach was preventing users from creating new variables within the switch statement. parseBody() will also return the block delimiting token, which can help in cases where blocks need to be chained together.
I tested with this example but it doesn't seem to be working yet.
int switchTest(int x) {
int result = 0;
switch (x) {
case 0:
result = 10;
break;
case 1:
result = 20;
break;
case 2:
result = 30;
break;
/*default: // its break the transpiler
result = -1;
break;*/
}
return result;
}
Result
Switch(x).Case(int( 0 ), () => {
result.assign( int( 10 ) );
break;
} ).Default( () => {
result.assign( int( 20 ) );
break;
} ).Default( () => {
result.assign( int( 30 ) );
break;
} );
I tested with this example but it doesn't seem to be working yet.
I will look at it later today and convert to draft for now. I'm not sure how comments work but it seems like the Decoder just ignores them in most instances.
Output seems to be good now, seemingly just a readToken order of operations issue (parseSwitchCaseBlock was erroneously reading/skipping case token again after already being skipped).
Is this how we generally want to style cases for switch statements in future TSL examples? (code output from latest commit)
Switch( x )
.Case( int( 0 ), () => {
result.assign( int( 10 ) );
Break();
} ).Case( int( 1 ), () => {
result.assign( int( 20 ) );
Break();
} ).Case( int( 2 ), () => {
result.assign( int( 30 ) );
Break();
} );
return result;
Also, though I do appreciate getting these changes in as soon as possible, I would appreciate some communication about requested code style, indentation changes, or missing/expected features in a code review rather than seeing them in a commit later on before I can attempt to address the issues myself. I largely use these PRs as an opportunity to improve myself as a programmer, and I would like to be involved in finishing and fully understanding the projects I start. If there's anything I can do on my end in terms of improving communication or my own code style to align it more with the project, please let me know.
Also, though I do appreciate getting these changes in as soon as possible, I would appreciate some communication about requested code style or indentation changes in a code review so that I can attempt to address the issues myself.
@cmhhelgeson Sure, we can do it like that in the next PR's and thanks for collaborating once again.
About the style, I wouldn't say it's definitive, it seems easier to read, we can continue like this for now.