2013/9/12 Mark S. Miller erig...@google.com
Membranes need shadow targets, because of non-extensibility of objects and
non-configurability of properties. This special case of
no-invariants-anywhere is not JavaScript. Trying to do membranes without
shadow targets is a useless exercise.
True,
Le 13/09/2013 09:19, Tom Van Cutsem a écrit :
2013/9/12 Mark S. Miller erig...@google.com mailto:erig...@google.com
Membranes need shadow targets, because of non-extensibility of
objects and non-configurability of properties. This special case
of no-invariants-anywhere is not
On Thu, Sep 12, 2013 at 11:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Sep 12, 2013, at 1:50 PM, Brendan Eich wrote:
I thought we agreed with Andreas Rossberg's proposal to isolate default
expressions from hoisted body declarations, as if (kind of) desugaring
Damned if I
2013/9/13 David Bruant bruan...@gmail.com
If one wants Object.getPrototypeOf to return the same object twice, the
membrane has to associate a new prototype with a given object. If there is
a shadow target, the place of where to store this object is pretty obvious
([[Prototype]]).
That said,
On 13 September 2013 11:27, Till Schneidereit t...@tillschneidereit.net wrote:
On Thu, Sep 12, 2013 at 11:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 12, 2013, at 1:50 PM, Brendan Eich wrote:
I thought we agreed with Andreas Rossberg's proposal to isolate default
Oliver Hunt mailto:oli...@apple.com
September 13, 2013 6:11 PM
Okay so we were discussing among ourselves, and we thought that a sane
desugaring for
function f(x=expr) {
...
}
would be
function f(x) {
if (arguments.length 1) x=expr;
...
}
ES6 has two things that go against this, already
Okay so we were discussing among ourselves, and we thought that a sane
desugaring for
function f(x=expr) {
...
}
would be
function f(x) {
if (arguments.length 1) x=expr;
...
}
This would produce a consistent and easy to follow semantic for default
evaluation, it doesn't introduce any
On Sep 13, 2013, at 9:18 AM, Brendan Eich bren...@mozilla.com wrote:
Oliver Hunt mailto:oli...@apple.com
September 13, 2013 6:11 PM
Okay so we were discussing among ourselves, and we thought that a sane
desugaring for
function f(x=expr) {
...
}
would be
function f(x) {
if
MarkM and I talked about conditional invocation offline and we convinced
ourselves to argue for the status-quo (i.e. continue to encode conditional
invocations as [[Get]]+[[Call]]).
The most compelling argument we can think of is that [[Get]]+[[Call]] is
also the pattern JavaScript programmers
On 13 September 2013 18:39, Oliver Hunt oli...@apple.com wrote:
The problem with temporal dead zones is that they lead to weird behaviour in
edge cases, and almost all of them should be syntactically identifiable as
errors up front. The problem is that you can only _almost_ get syntax
On Sep 13, 2013, at 9:58 AM, Andreas Rossberg rossb...@google.com wrote:
On 13 September 2013 18:39, Oliver Hunt oli...@apple.com wrote:
The problem with temporal dead zones is that they lead to weird behaviour in
edge cases, and almost all of them should be syntactically identifiable as
On Sep 13, 2013, at 11:09 AM, Andreas Rossberg rossb...@google.com wrote:
OK, I assumed you were talking about TDZ in general, and not just for
the specific case of parameter lists. For parameter lists, I agree
that there is no reason to treat them as mutually recursive. However,
if scoping
Oliver Hunt mailto:oli...@apple.com
September 13, 2013 6:39 PM
On Sep 13, 2013, at 9:18 AM, Brendan Eichbren...@mozilla.com wrote:
Oliver Huntmailto:oli...@apple.com
September 13, 2013 6:11 PM
Okay so we were discussing among ourselves, and we thought that a sane
desugaring for
function
On 13 September 2013 19:18, Oliver Hunt oli...@apple.com wrote:
On Sep 13, 2013, at 9:58 AM, Andreas Rossberg rossb...@google.com wrote:
On 13 September 2013 18:39, Oliver Hunt oli...@apple.com wrote:
The problem with temporal dead zones is that they lead to weird behaviour
in edge cases,
On 13 September 2013 20:17, Oliver Hunt oli...@apple.com wrote:
Introducing a new scope for each argument could be extraordinarily
expensive, also would make some semantics weird:
function f(a=1, b=function(){return a}) {
var a = 2;
return b() // What's this?
}
The semantics we tentatively
Tom Van Cutsem mailto:tomvc...@gmail.com
September 13, 2013 6:36 PM
MarkM and I talked about conditional invocation offline and we
convinced ourselves to argue for the status-quo (i.e. continue to
encode conditional invocations as [[Get]]+[[Call]]).
The most compelling argument we can think
Has a decision been made how to handle functions in blocks in sloppy mode? Did
I miss it?
Similarly: are only the bodies of modules implicitly strict? Or the bodies of
classes, too?
Given the trick with contextually interpreting `let` as a keyword in sloppy
mode, all ES6 features seem to be
See
https://mail.mozilla.org/pipermail/es-discuss/2013-February/028632.html,
find 3c. Absolute minimum intersection semantics [for function in
block outside of strict code], and (later) Class, Modules implicitly
strict.
/be
Axel Rauschmayer mailto:a...@rauschma.de
September 13, 2013
* You can pass undefined to trigger defaulting -- this is important for
composition / delegation.
No, it's a terrible feature :D i'm unaware of any language that supports
arbitrary ordering of arguments.
FWIW, ColdFusion allows to call functions with named parameters in an
arbitrary
Right.
Just to be super-clear, nothing like this is proposed for JS, for the
reason I gave.
/be
Sebastian Zartner mailto:sebastianzart...@gmail.com
September 13, 2013 11:52 PM
FWIW, ColdFusion allows to call functions with named parameters in an
arbitrary order.[1] This has one benefit:
* You can have default parameters before parameters without defaults.
The spec explicitly states that any parameter without a default, but after
another parameter that does have a default assignment implicitly has a
default property of undefined
As an aside: This can be useful. For example:
On Fri, Sep 13, 2013 at 2:52 PM, Sebastian Zartner
sebastianzart...@gmail.com wrote:
* You can pass undefined to trigger defaulting -- this is important for
composition / delegation.
No, it's a terrible feature :D i'm unaware of any language that supports
arbitrary ordering of arguments.
On Fri, Sep 13, 2013 at 3:06 PM, Axel Rauschmayer a...@rauschma.de wrote:
* You can have default parameters before parameters without defaults.
The spec explicitly states that any parameter without a default, but after
another parameter that does have a default assignment implicitly has a
```js
function getRandomInteger(lower = 0, upper) {
return Math.floor(Math.random() * (upper - lower)) + lower;
}
```
This doesn't do what you appear to think it does. In particular,
calling it with getRandomInteger(5) is *not* equivalent to calling
it with getRandomInteger(0, 5),
Axel Rauschmayer mailto:a...@rauschma.de
September 14, 2013 12:36 AM
Thanks! I didn’t look at the spec section, I (incorrectly) assumed I
knew how they worked. Then I don’t see a use case for this, I’d find
it confusing.
What alternative do you want?
1. Parameter default value before
Also see https://people.mozilla.org/~jorendorff/es6-draft.html#sec-B.3.2
It still has some issues I need to work, put it's my starting point.
Allen
Brendan Eich bren...@mozilla.com wrote:
See
https://mail.mozilla.org/pipermail/es-discuss/2013-February/028632.html,
find 3c. Absolute minimum
26 matches
Mail list logo
