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

Support else if (...) #27

Merged
merged 6 commits into from
Dec 16, 2017
Merged

Support else if (...) #27

merged 6 commits into from
Dec 16, 2017

Conversation

whitecrownclown
Copy link
Contributor

@whitecrownclown whitecrownclown commented Dec 15, 2017

resolves #19
Added support for if (...) else if (...) else {}
Added test

@coveralls
Copy link

Coverage Status

Coverage increased (+0.01%) to 92.882% when pulling 4574505 on whitecrownclown:master into 78e4f1b on ballercat:master.

@whitecrownclown whitecrownclown changed the title Support else if (...) #19 Support else if (...) Dec 15, 2017
@ballercat
Copy link
Owner

Hi and thanks. I'll take a look at the changes shortly.

Copy link
Owner

@ballercat ballercat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was missing in the original issue I submitted, but we should handle else if statements without {} as well.

@@ -26,7 +26,12 @@ const ifThenElse = (ctx: Context) => {

ctx.expect(["}"]);

if (ctx.eat(["else"])) {
while (ctx.eat(["else"])) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we are not handling the case where an engineer is omitting the {} brackets and using single statements.

if (x == 0) 
  return 1;
else if (x == 1)
  return 2;
else 
  return -1;

We should do that before we enable else if statements

return 4;
} else {
return 1;
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, let's add a test for

  • Where {} are omitted after if statements

@whitecrownclown
Copy link
Contributor Author

@ballercat Yep, i'll add those soon(~ish) and update the PR. Thanks!

@whitecrownclown
Copy link
Contributor Author

I've done some rework on this, should work as intended.

Supports curly braces/no curly braces
Added a test for it

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.003%) to 92.722% when pulling b60a2c5 on whitecrownclown:master into 882cd4b on ballercat:master.

Copy link
Owner

@ballercat ballercat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just a few suggestions.


// maybe a curly brace or not
// push statements while taking into consideration having curly braces or not
const doStatement = (node, isThenBranch, ctx) => {
Copy link
Owner

@ballercat ballercat Dec 16, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love how we pass through isThenBranch and node into this function. Mainly because it's not doing anything with the flags, it simply passes them through to pushStatement. These type of patterns are a code smell that a function is doing a bit too much.

I like that you split this out into its own function and I think doStatement should just eat as many statements as it can and return them in an array.

const doStatement = (ctx: Context) => {
   const statements = [];   
   if (ctx.eat(["{"])) {
      while(...) {
         statements.push(statement(ctx));
      }
      ...
   } else {
      statements = statement(ctx);
     ...
   }

   // filter out null statments, these should really be fixed in general :/
   return statements.filter(stmt => stmt != null);
}

ctx.eat(["if"]);
// First operand is the expression
doIfExpression(node, ctx);
doStatement(node, isThenBranch, ctx);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you apply my comments above we could just do

node.then = doStatement(ctx);

isThenBranch = true;
doIfExpression(node, ctx);
}
doStatement(node, isThenBranch, ctx);
Copy link
Owner

@ballercat ballercat Dec 16, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need isThenBranch or pushStatement. Let's just simplify a bit by

if (ctx.eat(['if'])) {
   doIfExpression(node, ctx);
   node.then = [...node.then, doStatement(ctx)];
} else {
   node.else = [ ...node.else, doStatement(ctx)];
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, i had an uglier implementation before that worked. Your ideea is better. I'll update the PR with the changes (test cases for all branches as well)

// push statement based on then/else branch
const pushStatement = (node, isThenBranch, stmt) => {
if (!stmt) return;
if (isThenBranch) return node.then.push(stmt);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heads up, I added eslint validation to travis so single line if statements will be a warning from now on. Just try to avoid these.

https://travis-ci.org/ballercat/walt/builds/317486874#L485

y = 4;
else
y = 1;
return y;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the tests.

Please make test take an i32 argument for x so that we could test all the branches, I want to make sure we cover all the scenarios.

something like this would work

WebAssembly.instantiate(compile(src)).then(({ instance: { exports } }) => {
   t.is(exports.test(0), 2);
   t.is(exports.test(1), 4);
   t.is(exports.test(-1), 1);
});

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.03%) to 92.7% when pulling 26907b0 on whitecrownclown:master into 882cd4b on ballercat:master.

@ballercat ballercat merged commit c1eb5f0 into ballercat:master Dec 16, 2017
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.

Support else if (...)
3 participants