...

View Full Version : return not in function



pg300
09-08-2008, 11:19 AM
This is seriously giving me a huge headache. When uFuncs is 'alert("half")' it does what you expect it to alerts a then half then b. but when uFuncs='return' it alerts a then throws error "return not in function". How can i make the return be evaluated? :(



function test(uFuncs)
{

alert('a');
eval(uFuncs);
alert('b');

}


Thanks! :)

liorean
09-08-2008, 03:28 PM
eval cannot introduce abrupt termination into a scope. So, no return.

vwphillips
09-08-2008, 04:05 PM
What is uFuncs?

if it is a function name

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
<title></title>
<script language="JavaScript" type="text/javascript">
/*<![CDATA[*/
function test(uFuncs)
{

alert('a');
window[uFuncs]();

}

function Test(){
alert('b');

}

/*]]>*/
</script></head>

<body>
<input type="button" name="" value="TEST" onclick="test('Test')" />
</body>

</html>

liorean
09-08-2008, 04:14 PM
Even with Vic's solution, you can't add abrupt termination, though. Not without writing an if-statement that returns depending on the return value of whatever you do in the middle.

Kor
09-08-2008, 04:59 PM
After all, return is not an expression, thus it can not be evaluated.

rnd me
09-09-2008, 06:38 AM
eval breaks out of the current scope, running at global level. thus, the "return" would not actually be executing in your function.

pg300
09-09-2008, 09:24 AM
Ah i see. So the only way is to add something like this:
function test(uFuncs)
{

alert('a');
eval(uFuncs);
if(pseudoReutrn) { return }
alert('b');

}

liorean
09-09-2008, 07:32 PM
eval breaks out of the current scope, running at global level. thus, the "return" would not actually be executing in your function.Actually, that is not true. The code eval runs is always run in the current scope, so if it's run in a function it will be executing in the function. It's actually one of the mistakes in designing JavaScript that Brendan Eich did that we sadly can't get rid of now.

rnd me
09-10-2008, 03:16 AM
Actually, that is not true. The code eval runs is always run in the current scope, so if it's run in a function it will be executing in the function. It's actually one of the mistakes in designing JavaScript that Brendan Eich did that we sadly can't get rid of now.
you are in practice correct. i was thinking of Function code, which is always global. i made and use an eval2 based upon Function, and tired at night, i got them mixed up. please forgive me.

technically, a new context (an hence scope) is created for eval, and old properties are copied, which is why it is so slow.
from the spec: 10.2.2 : "The scope chain is initialised to contain the same objects, in the same order, as the calling context's
scope chain. This includes objects added to the calling context's scope chain by with statements and
catch clauses."

at least th OP got the point...

ps: you can specify the scope for eval in firefox by passing it as a second argument. this will be removed in 3.1 because it can reverse engineer private variables closed inside public objects.

liorean
09-10-2008, 04:29 AM
technically, a new context (an hence scope) is created for eval, and old properties are copied, which is why it is so slow.No a new context is not added, you're reading the spec text wrong. And no, that is not the reason it's slow. The reason it's slow is that it has to fire up a fully featured ECMAScript parser to generate the AST which it has to either interpret or compile into bytecode which in turn can either be interpreted or JIT compiled into machine code to be executed. Or in the case of the V8 engine Google Chrome ships with, skip the bytecode and go directly on JITting the AST into machine code.

from the spec: 10.2.2 : "The scope chain is initialised to contain the same objects, in the same order, as the calling context's scope chain. This includes objects added to the calling context's scope chain by with statements and catch clauses."And if you read this again, you should see the obvious: It's operating not on a new context, but the exact same context, since all objects in the scope of eval are not copies of, but the same objects as the calling context contained.

at least th OP got the point...

ps: you can specify the scope for eval in firefox by passing it as a second argument. this will be removed in 3.1 because it can reverse engineer private variables closed inside public objects.Yeah, it was a bad idea to allow it, but at least we haven't seen any exploits of it so far, only potential for it. There are similar problems with __proto__ being writable which are also being addressed by the ECMAScript committee (by specifying only read and not write access to the prototype).



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum