Maybe everything is not accurate regarding some comments and annex
should include other examples but, before writing more, let's submit it
As mentionned in the gist, it is supposed to address several topics :
security and wrapping, modules, multiple globals, VMs and proxies
It did not come up just this morning, it can be called a |with|
"nothing" proposal, |with| is not light in specs and rarely used, it was
eliminated in strict mode (even if some non strict/strict mode
combinations use it, see recent cajaVM analysis) but maybe strict mode
can give it another meaning.
The concept is simple and based on the implementation of VMs where if
you have to pass something to |with| or other, then it's totally
impossible to separate it completely from the initial scope (see annex)
There is a disruptive assignment floating in the |with|'s code :
"this=window" (which then sets the ThisBinding and associated var
bindings), which has to follow some rules (must be in root, can not be
invoked twice, etc), might look strange but it's a kind of LHS lexical
|this|, so maybe no more disruptive than the lexical this
At the end the result is simple and simple to use, does eliminate a lot
of complications, is flexible (you can decide whether |with| stuff
reminds isolated or not and vice-versa, clone global var or not, freeze
stuff or not, etc), and probably light in terms of specs
modifications/implementation.
Draft is here : https://gist.github.com/edd064e5b29e67ebe493
Maybe everything is not accurate regarding some comments and annex
should include other examples but, before writing more, let's submit it
As mentionned in the gist, it is supposed to address several topics :
security and wrapping, modules, multiple globals, VMs and proxies
It did not come up just this morning, it can be called a |with|
"nothing" proposal, |with| is not light in specs and rarely used, it was
eliminated in strict mode (even if some non strict/strict mode
combinations use it, see recent cajaVM analysis) but maybe strict mode
can give it another meaning.
The concept is simple and based on the implementation of VMs where if
you have to pass something to |with| or other, then it's totally
impossible to separate it completely from the initial scope (see annex)
There is a disruptive assignment floating in the |with|'s code :
"this=window" (which then sets the ThisBinding and associated var
bindings), which has to follow some rules (must be in root, can not be
invoked twice, etc), might look strange but it's a kind of LHS lexical
|this|, so maybe no more disruptive than the lexical this
At the end the result is simple and simple to use, does eliminate a lot
of complications, is flexible (you can decide whether |with| stuff
reminds isolated or not and vice-versa, clone global var or not, freeze
stuff or not, etc), and probably light in terms of specs
modifications/implementation.
--
jCore
Email : avitte at jcore.fr
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Draft is here : gist.github.com/edd064e5b29e67ebe493
Maybe everything is not accurate regarding some comments and annex should include other examples but, before writing more, let's submit it
As mentionned in the gist, it is supposed to address several topics : security and wrapping, modules, multiple globals, VMs and proxies
It did not come up just this morning, it can be called a |with| "nothing" proposal, |with| is not light in specs and rarely used, it was eliminated in strict mode (even if some non strict/strict mode combinations use it, see recent cajaVM analysis) but maybe strict mode can give it another meaning.
The concept is simple and based on the implementation of VMs where if you have to pass something to |with| or other, then it's totally impossible to separate it completely from the initial scope (see annex)
There is a disruptive assignment floating in the |with|'s code : "this=window" (which then sets the ThisBinding and associated var bindings), which has to follow some rules (must be in root, can not be invoked twice, etc), might look strange but it's a kind of LHS lexical |this|, so maybe no more disruptive than the lexical this
At the end the result is simple and simple to use, does eliminate a lot of complications, is flexible (you can decide whether |with| stuff reminds isolated or not and vice-versa, clone global var or not, freeze stuff or not, etc), and probably light in terms of specs modifications/implementation.