Would this work? combining two evil functions...

[odysseus654]

I have just discovered the "with" statement, which up until now I have
only known as "that which should never be used". I would like to
evaluate some commands (such as function definitions and the like)
within the global context, would this accomplish the task? Are there
better ways to deal with this? (Note that I am making dynamic
execution a requirement)

function executeAsGlobal(cmd)
{
with(window) exec(cmd);
}

[Randy Webb]

od*********@gmail.com said the following on 8/29/2006 9:58 PM:

I have just discovered the "with" statement, which up until now I have
only known as "that which should never be used".

That's not a true statement though. "with" can be used, and has it's
benefits.

I would like to evaluate some commands (such as function definitions
and the like) within the global context, would this accomplish the task?

Perhaps.

Are there better ways to deal with this? (Note that I am making dynamic
execution a requirement)

window[cmd]();

Not 100% sure if that gets it back into the global context though as it
is being called from within a function.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[RobG]

Randy Webb wrote:

od*********@gmail.com said the following on 8/29/2006 9:58 PM:

I have just discovered the "with" statement, which up until now I have
only known as "that which should never be used".

That's not a true statement though. "with" can be used, and has it's
benefits.

I would like to evaluate some commands (such as function definitions
and the like) within the global context, would this accomplish the task?

Perhaps.

Are there better ways to deal with this? (Note that I am making dynamic
execution a requirement)

window[cmd]();

Not 100% sure if that gets it back into the global context though as it
is being called from within a function.

Then:

var _global = this;

function testCommands()
{
/* evaluate _global[cmd] */
}

should remove all doubt and cover environments that don't have a window
object.
-
Rob

[Randy Webb]

RobG said the following on 8/29/2006 10:53 PM:

Randy Webb wrote:

>od*********@gmail.com said the following on 8/29/2006 9:58 PM:

>>I have just discovered the "with" statement, which up until now I have
only known as "that which should never be used".

That's not a true statement though. "with" can be used, and has it's
benefits.

>>I would like to evaluate some commands (such as function definitions
and the like) within the global context, would this accomplish the task?

Perhaps.

>>Are there better ways to deal with this? (Note that I am making dynamic
execution a requirement)

window[cmd]();

Not 100% sure if that gets it back into the global context though as it
is being called from within a function.

Then:

var _global = this;

function testCommands()
{
/* evaluate _global[cmd] */
}
should remove all doubt

Does it? Context is key and without context of what the OP is doing, you
can't answer my question :)

and cover environments that don't have a window object.

If you are going to cover environments that don't have a window object,
then you also have to consider any potential environments that may not
have a global context.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[RobG]

Randy Webb wrote:

RobG said the following on 8/29/2006 10:53 PM:

Randy Webb wrote:

od*********@gmail.com said the following on 8/29/2006 9:58 PM:

[...]

>Are there better ways to deal with this? (Note that I am making dynamic
execution a requirement)
window[cmd]();

Not 100% sure if that gets it back into the global context though as it
is being called from within a function.

Then:

var _global = this;

function testCommands()
{
/* evaluate _global[cmd] */
}
should remove all doubt

Does it? Context is key and without context of what the OP is doing, you
can't answer my question :)

Are you referring to "as per the specification" or "in reality"?

According to the ECMAScript Language Specification, section 10.2, when
used in a global context, the this operator refers to the global object
- it is quite explicit about that. Therefore _global *must* refer to
the global object and _global[propertyName] must be interpreted as a
reference to a property of the global object. I'm keen to know if I've
got that wrong.

It therefore follows that if _global does not refer to the global
object, then the implementation does not conform to the spec. I don't
know of any such implementation, but I'm certainly no authority on
that. :-)

and cover environments that don't have a window object.

If you are going to cover environments that don't have a window object,
then you also have to consider any potential environments that may not
have a global context.

That was a throwaway line, I expect 99.99% of all ECMA-based script
appearing in this group is intended to only ever run in a browser - the
odd LiveScript fossil or ActionScript reactionary being exceptions
rather than the rule. I expected a few Mac OS X Dashboard widget
questions, but they are few and far between - maybe they get better
satisfaction in Apple's ADC forum. ;-).
--
Rob

[Randy Webb]

RobG said the following on 8/30/2006 12:46 AM:

Randy Webb wrote:

>RobG said the following on 8/29/2006 10:53 PM:

>>Randy Webb wrote:
od*********@gmail.com said the following on 8/29/2006 9:58 PM:

[...]

>>>>Are there better ways to deal with this? (Note that I am making dynamic
execution a requirement)
window[cmd]();

Not 100% sure if that gets it back into the global context though as it
is being called from within a function.
Then:

var _global = this;

function testCommands()
{
/* evaluate _global[cmd] */
}
should remove all doubt

Does it? Context is key and without context of what the OP is doing, you
can't answer my question :)

Are you referring to "as per the specification" or "in reality"?

I think you already know the answer to that based on my opinions of the
specifications that I have expressed in the past. But just in case, to
answer the question:

"in reality" - without a doubt.

No implementation follows the specification 100% exactly and there may -
or may not - be one that follows the global aspect of the specs.

>>and cover environments that don't have a window object.

If you are going to cover environments that don't have a window object,
then you also have to consider any potential environments that may not
have a global context.

That was a throwaway line, I expect 99.99% of all ECMA-based script
appearing in this group is intended to only ever run in a browser

If it is that low of a percentage :)

- the odd LiveScript fossil or ActionScript reactionary being exceptions
rather than the rule.

True. And most of those get referred to other groups that deal with them
exclusively.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Lasse Reichstein Nielsen]

od*********@gmail.com writes:

I have just discovered the "with" statement, which up until now I have
only known as "that which should never be used".

Closer to "use with *extreme* care", because you have no way of knowing
what properties exist on the object you are "with"'ing with.

I would like to evaluate some commands (such as function definitions
and the like) within the global context, would this accomplish the
task? Are there better ways to deal with this? (Note that I am
making dynamic execution a requirement)

function executeAsGlobal(cmd)
{
with(window) exec(cmd);

No.

What "with" does is to add its operant to the scope chain before executing
the statements.
That means that the statement "exec(cmd)" is executed with variables
being resolved against the global object first, and the scope chain
of the "executeAsGlobal" closure afterwards. That is all.
It does not change the value of the "this" operator, or of the variables
object. That means that variables created by "exec(cmd)" will end up
in the variables objec of the invocation of "executeAsGlobal", not in
the global scope.
This might be sufficient for your use, but it is not the same as
executing within the global context.

Also, the command given here as example, "exec(cmd)" is a simple function
call. Both "exec" and "cmd" are looked up with the global object first
(potentially overriding the function parameter "cmd" if the global object
contains a "cmd" property), but the execution of the function "exec" will
happen in the scope chain stored in that function's closure.

If you mean "eval" instead of "exec", then the "cmd" code is executed
in the same scope as the call, so it inherits the enhanced scope chain
and the unchanged variables object. I.e.

function foo() {
with (window) { eval("var x = 42;"); }
}
foo();

would not create "x" as a global variable.

I have used this trick myself, but one has to be aware of the limitations.

(The only way I know of to have code executed in the global scope from
inside a function scope is to use setTimeout/setInterval with a string
parameter, but you can't do that synchroneously).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[odysseus654]

Lasse Reichstein Nielsen wrote:

If you mean "eval" instead of "exec", then the "cmd" code is executed
in the same scope as the call, so it inherits the enhanced scope chain
and the unchanged variables object. I.e.

function foo() {
with (window) { eval("var x = 42;"); }
}
foo();

would not create "x" as a global variable.

I have used this trick myself, but one has to be aware of the limitations.

Figures. I've been doing some regexp stuff lately and seem to confuse
exec and eval way too much...

Yah, currently our logic is retrieving javascript function definitions
(and calls) as part of the dynamic page operation. Considering that
"function xyz(abc){}" dumps itself into the current variable scope, was
hoping for a way to be able to change that scope. Currently we're
using "xyz = function(abc) {}" without first declaring xyz, which
appears to work but gives jslint fits. Was hoping for a cleaner method.