What happened to return values? about jint HOT 10 CLOSED

I forked and made the changes to remove the unnecessary check for return outside of functions, and the call to GetCompletionValue() so that Run() would be

public object Run( string js ) {
return Execute(js).GetCompletionValue();
}

https://github.com/greggwon/jint/commit/215d3895edde32bee97cd66e1024b15ba2e6dca6

from jint.

Thank you for looking into this.

First I would suggest to use an anonymous function like this:

(function () {
    // your code goes here
})();

This would fix your argument about having to define a named function.

Then, instead of having users to use a return statement, it would be simpler to just call GetCompletionValue without wrapping the code in a function, it already works. So in the end, you method is really just removing the need of GetCompletionValue().

In this case, would you please change your code to call it Evaluate and just wrap GetCompletionValue().ToObject() ?

from jint.

@greggwon I was running into a similar issue. Our users can write scripts and sometimes they use a return statement and sometimes they don't. I found that you can use the Tolerant flag for the parser to allow a return statement outside of a function.

var engine = new Engine();
engine.Execute("return 0;", new ParserOptions
{
    Tolerant = true
});

I don't know if this is the intended use -- but it seems to work.

from jint.

Oh man, I didn't even know that, awesome feature. We should document it somewhere ;)

from jint.

@sebastienros I guess I'm confused -- I thought you had coded the parser. Or are you joking?

from jint.

I am not joking ;) I work on so many different things that I tend to forget after a few months. But his one might also be explained because I actually ported the parser from Esprima, so I did not actually made the logic behind it. Converted to C# and improved some code paths.

from jint.

After looking into the code, the goal of this option is to not throw on parse errors but instead add these error into an internal collection program.Errors that you can analyze afterwards. Some of the parser errors can then be treated as warning and still be run. This example you are providing is one of the acceptable syntax errors. Maybe it's about time to provide some little documentation as part of the wiki ...

from jint.

I guess my question is, why would you care where i put a return statement? What
does this tolerant flag do, to improve software correctness? In the end,
imbedding javascript for application scripting is always going to end up with an
expression to be executed and a return value is the best way to know that
whatever expression you executed was successfully completed. So, for me, it
makes little sense for the default to be "not" to allow return in the script.
There are times in our app, when I need to debug the script we are running, and
so I return an intermediate value, in the middle of the script by just using
"return intermediatValue;" with the existing code after that. I don't want to
fight with the runtime environment to get real work done. I need to run
javascript and I need to always have the ability to see a return value from that
execution.

This was possible in the previous 0.X version, so I am not sure I understand how
this change adds value to the overall system? Is there some disastrous use case
where a return in the middle of a non-function block of code is somehow a
terrible mistake?

Our code is typically a script that has prepended a bunch of assignments of
values that our app knows about. The script is just a bunch of if statements
with returned values. So, while its possible to do what you show below, the
real questions is, why does it make sense to do this now? What's the
advantage? How does Tolerant = true make the software system more performant or
more useful or more correct? Either it's right to return a value in a script,
or it's not.

This feels like useless overhead. Deferring "correctness" checks to run time
failures just creates more fragile code. In this case, it causes runtime
"exceptions" that are going to terminate the app (.Net should have checked
exceptions, and since it doesn't, people write fragile code, not knowing when to
catch exceptions because they can be added after the code is written, and then
there is now, no way to know about new failure modes without line by line
inspection), rather than improve the software systems' stability and usability.

Gregg Wonderly

On 9/25/2014 11:42 AM, Brian Beard wrote:

@greggwon https://github.com/greggwon I was running into a similar issue.
Our users can write scripts and sometimes they use a |return| statement and
sometimes they don't. I found that you can use the |Tolerant| flag for the
parser to allow a return statement outside of a function.

var engine = new Engine();
engine.Execute("return 0;", new ParserOptions
{
Tolerant = true
});

I don't know if this is the intended use -- but it seems to work.

—
Reply to this email directly or view it on GitHub
#75 (comment).

from jint.

@sebastienros Ah, that makes sense -- I know what you mean about forgetting. BTW -- Thanks for writing this great library.

from jint.

@greggwon Jint 2 is a complete rewrite, not a single line of code was used from Jint 1 and all decisions have been thrown away, with one direction: following the specification. And the specification states that a return statement is invalid outside of a function.

Btu what is great is that you have solutions for that, your only issue is to decide which one:

• use the Parser options as @honestegg mentioned
• wrap all your users' code into a function like I already explained in another comment
• fork the source and make the defaults you want

I might change my mind as I often do if I am given convincing arguments, but right now I won't change the default behavior.

from jint.