Douglas Crockford wrote:
On 4/23/2012 6:41 PM, Mark S. Miller wrote:
On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
The point is that much of what is done on the web is not high
integrity computation. It is essential that
On 4/24/2012 1:28 PM, Brendan Eich wrote:
http://www.imdb.com/title/tt0076759/quotes?qt=qt0440727
http://www.imdb.com/title/tt0121766/quotes?qt=qt0333083
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Apr 24, 2012, at 1:28 PM, Brendan Eich wrote:
Douglas Crockford wrote:
On 4/23/2012 6:41 PM, Mark S. Miller wrote:
On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
The point is that much of what is done on the web is not
Allen Wirfs-Brock wrote:
Back to the original point, which was that making strict mode delete
throw when applied to a non-configurable property is not significantly
higher integrity than the non-strict behavior of returning false when
a property can not be deleted.
On Apr 23, 2012, at 10:15 AM, Andreas Rossberg wrote:
On 21 April 2012 01:22, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Here are a few design alternates that have come up as I work the
specification draft for arrow functions
1) Always strict? Should all arrow functions be considered
I'd prefer if concise method syntax stayed simple syntactic sugar for
functions. Methods obviously need dynamic this. If you combine that
with changes like the above, then you have implicitly introduced a
third kind of function that cannot be described as (simple) syntactic
sugar for any of
Andreas Rossberg wrote:
To be honest, that suggestion confirms one of my fears about 1JS --
ending up with a more complicated language with ad-hoc rules about
which mode applies in which context. Please let's try to resist the
temptation. As much as I would like to encourage strict mode, I think
Andreas Rossberg wrote:
On 21 April 2012 01:22, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
7) All of the above questions also apply to functions defined using concise
method syntax in object literals or classes. Should the same answers apply to
them?
I'd prefer if concise method syntax
On Apr 23, 2012, at 8:19 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
To be honest, that suggestion confirms one of my fears about 1JS --
ending up with a more complicated language with ad-hoc rules about
which mode applies in which context. Please let's try to resist the
temptation. As
6) Do arrow functions need to have per instance caller and arguments
poison pill properties?
I propose no, because they are a new feature. But we can include a NOTE
warning against providing their non-standard legacy implementation.
For simplicity and uniformity, I'd keep the same
Brandon Benvie wrote:
6) Do arrow functions need to have per instance caller and
arguments poison pill properties?
I propose no, because they are a new feature. But we can include
a NOTE warning against providing their non-standard legacy
implementation.
For
On Apr 23, 2012, at 10:18 AM, Brandon Benvie wrote:
6) Do arrow functions need to have per instance caller and arguments
poison pill properties?
I propose no, because they are a new feature. But we can include a NOTE
warning against providing their non-standard legacy
Allen Wirfs-Brock wrote:
This raises the issue that ES5.1 overlooked poisoning caller/arguments
for Function.prototype. Only function object created using the
algorithm in 13.2 have the the poison pill properties and
Function.prototype is not specified using 13.2.
Function.prototype is
On Apr 23, 2012, at 11:15 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
This raises the issue that ES5.1 overlooked poisoning caller/arguments for
Function.prototype. Only function object created using the algorithm in
13.2 have the the poison pill properties and Function.prototype is
Allen Wirfs-Brock wrote:
caller and arguments properties on functions are a non-standard extension,
Right you are:
js Function.prototype.caller
null
js Function.prototype.arguments
null
and of course this is heap not code, so strictness doesn't enter into it.
Still happy to change our
I'm becoming increasing convinced that the poison pill approach to securing
the caller chain is a poor approach. We keep finding leaks in and it does
nothing to prevent implementation from inventing new ways to expose the
stating they are trying to hide. I now think we would be better off
The threat (not sure how real) is not a string telling the backtrace,
it's an object reference to an ancestor function in the call stack.
/be
Domenic Denicola wrote:
I'm becoming increasing convinced that the poison pill approach to securing the
caller chain is a poor approach. We keep
On Mon, Apr 23, 2012 at 11:15 AM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
This raises the issue that ES5.1 overlooked poisoning caller/arguments
for Function.prototype. Only function object created using the algorithm
in 13.2 have the the poison pill properties and
On Mon, Apr 23, 2012 at 11:42 AM, Brendan Eich bren...@mozilla.org wrote:
The threat (not sure how real) is not a string telling the backtrace, it's
an object reference to an ancestor function in the call stack.
The ancestor function leak is vastly worse than the backtrace into leak,
but both
Brendan Eich wrote:
Without arguments runtime semantic shifts, and with |this| lexical,
there aren't many strict mode changes left IIRC, and they are pretty
edgy edge cases.
Dave Herman pointed out the shift for |this|-binding in function nested
in arrow, under the proposal that arrow
On Apr 21, 2012, at 1:38 PM, Angus Croll wrote:
a function shouldn’t work radically (and silently!) different depending on
how it is invoked
every current JS function behaves exactly this way :-)
No, not at all. What Axel is saying is that you're proposing a new distinction
that *does not
On Apr 23, 2012, at 2:45 PM, David Herman wrote:
You cannot distinguish whether a function was called as a method, as a
function, or via .call/.apply. There's no way to tell.
PS Well, there's stack inspection, but we're all grownups here.
Dave
___
On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote:
Brendan Eich wrote:
Without arguments runtime semantic shifts, and with |this| lexical, there
aren't many strict mode changes left IIRC, and they are pretty edgy edge
cases.
True enough, but I hang tough on wanting arrows to imply
, April 23, 2012 19:11
To: Brendan Eich
Cc: es-discuss
Subject: Re: A few arrow function specification issues
On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote:
Brendan Eich wrote:
Without arguments runtime semantic shifts, and with |this| lexical,
there aren't many strict mode changes left
...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org (mailto:boun...@mozilla.org)] On Behalf Of David Herman
Sent: Monday, April 23, 2012 19:11
To: Brendan Eich
Cc: es-discuss
Subject: Re: A few arrow function specification issues
On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote
Strict mode delete non-configurable is one of the only offenders on the
this really shouldn't be an error list. The useful functionality no
longer allowed list is a couple of key things: caller for debug tracing,
and `var` in define. The latter was an issue with Narcissus running in V8
--harmony
`var` in eval I meant (and `const` in Narcissus's case)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
] On Behalf Of David Herman
Sent: Monday, April 23, 2012 19:11
To: Brendan Eich
Cc: es-discuss
Subject: Re: A few arrow function specification issues
On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote:
Brendan Eich wrote:
Without arguments runtime semantic shifts, and with |this| lexical
On Apr 23, 2012, at 4:59 PM, Domenic Denicola wrote:
As a day-to-day user who was not using strict until recently (stubborn other
team member for the loss), I can say that moving to strict was much more a
cleanup experience than a mode experience, with only a few small
exceptions:
1)
On Mon, Apr 23, 2012 at 5:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 23, 2012, at 4:59 PM, Domenic Denicola wrote:
As a day-to-day user who was not using strict until recently (stubborn
other team member for the loss), I can say that moving to strict was much
more a cleanup
On Apr 23, 2012, at 6:09 PM, Mark S. Miller wrote:
On Mon, Apr 23, 2012 at 5:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
...
The delete issue is very much along the lines of what I was referring to in
another thread[3] today regarding failure oblivious computing. I
On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
The point is that much of what is done on the web is not high integrity
computation. It is essential that high integrity be possible, when it is
required. But forcing all computation into the high integrity
+1 High integrity engineering of components supports low integrity
integration essential for low cost adaptable systems. We have scripting for
the same reason we carpenters. We could build a house using a computer
milling machine but no one could afford it; we don't want JavaScript to
enforce high
This is why I posited an explicit switch. Right now we're all talking about
secondary triggers for a very important component. Why isn't it just an
explicit choice? Why can't I install a foot gun where I know I have foot
armor plating? The goal being that when my users, without such armor, are
Here are a few design alternates that have come up as I work the specification
draft for arrow functions
1) Always strict? Should all arrow functions be considered strict functions?
Pros
It's a new syntactic form, so it is it easy to make it be an implicit opt-in to
strict mode.
We generally
Allen Wirfs-Brock wrote:
1) Always strict? Should all arrow functions be considered strict functions?
Pros
P1. It's a new syntactic form, so it is it easy to make it be an implicit
opt-in to strict mode.
P2. We generally want to encourage use of strict mode.
P3. If not, there would no way to
4) Should it be a dynamic error to try to use apply/call to set the this
binding of an arrow function.
Cons
To much existing code speculatively binding the this value when invoking
a function.
I propose that call/apply simply ignore the this value when invoked on an
arrow function.
What is the
I am in agreement with Angus on this one.
If there is no skinny arrow, hard |this| binding should not be part of the
spec. Fat arrow functions should default to lexical |this|, but if there is
no skinny arrow, it should not be a hard binding and call/apply should be
allowed, as well as bind,
On
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Angus Croll
Sent: Saturday, April 21, 2012 16:03
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: A few arrow function specification issues
4) Should it be a dynamic
I am in agreement with Angus on this one.
If there is no skinny arrow, hard |this| binding should not be part of the
spec. Fat arrow functions should default to lexical |this|, but if there is
no skinny arrow, it should not be a hard binding and call/apply should be
allowed, as well as
-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Angus Croll
Sent: Saturday, April 21, 2012 16:03
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: A few arrow function specification issues
4) Should it be a dynamic error to try to use
a function shouldn’t work radically (and silently!) different depending
on how it is invoked
every current JS function behaves exactly this way :-)
I'm painfully aware that I sound like a broken record on this, but
introducing a hard-bound function option while continuing to suport
dynamic-bound
a function shouldn’t work radically (and silently!) different depending on
how it is invoked
every current JS function behaves exactly this way :-)
`this` when not invoking a function as a method:
1. Bearable: this === undefined
2. Nasty: this === window
3. Very nasty: lexical this
I'm
On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer a...@rauschma.de wrote:
Counter-question: Isn’t it clear when you create a function whether it is
going to be a non-method function or a method?
It's clear to the implementer - Its not clear to a function that gets it as
an argument -
Angus Croll wrote:
On Sat, Apr 21, 2012 at 3:06 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de wrote:
Counter-question: Isn’t it clear when you create a function
I would argue that – in ES.next – whenever a function is passed as an
argument, one should always assume that it is a non-method function and
completely ignore `this`.
This makes me sad. Seems like functions are going to be a little less first
class than they were before - and for fairly
I understand your argument, but I think it is more important to be able to
switch in full to the new function operator(s), not sometimes one, other
times the other.
Why? Arrow functions and traditional functions serve different semantic
purposes. Why is it important to you that we
Using `=` but being forced to using `function` anytime I want dynamic this
just doesn't work.
That may be the crux of the matter. I’d say: In new code, use a method
definition any time you want dynamic `this`. In old code, use a function
expression.
--
Dr. Axel Rauschmayer
a...@rauschma.de
48 matches
Mail list logo
