On Jun 19, 2008, at 4:49 PM, Mark S. Miller wrote:
ES3 says:
10.2.2Eval Code
When control enters an execution context for eval code, the previous
active execution context, referred to as the calling context, is used
to determine the scope chain, the variable object
Lars Hansen wrote:
In my opinion the following is roughly right:
obj.eval(x)
if eval is the original global eval function then
if obj is an ES global object (window, frame) then
invoke eval as follows:
the scope chain holds that window (global) object only
Lars,
Could you comment on this?
I see from your post @
http://www.nabble.com/Eval-invisible-let-bindings-td14182651.html#a14182651
that you have definite ideas about the current ES4 proposal for
eval. What is that proposal? Is it written down anywhere?
I tried the reference
Both good points. Thanks.
--lars
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of liorean
Sent: 6. mars 2008 15:32
To: es4-discuss@mozilla.org
Subject: Re: eval
On 06/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
eval(x)
look up eval
Hi all.
I'm trying to implement an ES4-compliant version of eval, but I'm
having trouble understanding what the specified behavior is.
In ES4,
eval(x)
is distinct from all of
window.eval(x)
eval.call(myThisObject, x)
frames[0].eval(x)
in that the first form
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Reilly
Sent: 7. desember 2007 01:16
Don't you have to do scope chain dance for function closures
anyways or did I miss something? How is eval different from
function closures?
I think
On 2007-12-07, at 05:06 EST, Lars Hansen wrote:
That may in turn require heap-allocating individual
captured storage cells in order to avoid capturing entire rib objects,
which in its turn may cause overall slowdowns in code that does use
closures.
My experience is that closures are poorly
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Igor Bukanov
Sent: 5. desember 2007 23:53
To: es4-discuss@mozilla.org
Subject: Eval-invisible let bindings
Hi,
Currently ES4 allows to access from eval scripts the names
introduced by the let
On Dec 6, 2007 12:25 PM, Igor Bukanov [EMAIL PROTECTED] wrote:
On 06/12/2007, Lars Hansen [EMAIL PROTECTED] wrote:
Such an implementation only needs to detect direct
uses of eval, as specified in ES3 and elaborated in ES4. (ES4
specifies the meaning of strictly more uses of eval than ES3
Don't you have to do scope chain dance for function closures anyways or did I
miss something? How is eval different from function closures?
The notion piques my curiousity though. We here at Adobe have large AS3 code
bases where it is frowned upon to use function closures b/c local variable
Hi,
Currently ES4 allows to access from eval scripts the names introduced
by the let statements and expressions. It leads to implementation
complexity since the let bindings cannot be implemented as a pure
compilation-time feature and the runtime must be able to expose the
names for eval scripts
On Nov 1, 2007 3:46 PM, Kris Zyp [EMAIL PROTECTED] wrote:
It's a sandbox, right? Should be safe. Not so fast:
last they gave up. rexec was removed from the language.
With the complexity of creating and verifing a sandboxing eval that allows
shared mutable objects with some degree
But the only point I was trying to make was that providing a fun
eval(s, obj) and encouraging users to roll their own sandboxes would
be irresponsible.
Point taken, you are right. I still hope that some type of sandboxing can be
developed though
13 matches
Mail list logo