On 15 April 2014 18:06, Allen Wirfs-Brock allen.wirfsbr...@gmail.com wrote:
AWB: We _could_ add a `return()` method.
... It's a bigger change, but we could make for-of invoke `return()` on exit
or completion
This would be a _significant_ cost. One reason we got rid of the
StopIteration
The way destructuring assignment currently is specified leads to
rather inconsistent evaluation order. Consider:
let o = {}
function f() { print(1); return o }
function g() { print(2); return 5 }
f().x = g()// 1, 2
{a: f().x} = {a: g(}} // 2, 1
That is, destructuring assignments
On 29 April 2014 20:35, David Herman dher...@mozilla.com wrote:
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
Indeed I expect that in
practice most iterators in an ES6 program will be map, set, and array
iterators, which in practice will not be implemented with generators.
-example?
On Wed, Apr 30, 2014 at 3:48 AM, Andreas Rossberg rossb...@google.com
wrote:
On 29 April 2014 20:35, David Herman dher...@mozilla.com wrote:
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
Indeed I expect that in
practice most iterators in an ES6 program will be map
On 2 May 2014 14:45, Claude Pache claude.pa...@gmail.com wrote:
The algorithm given in [Bug 1908, comment 2]
(https://bugs.ecmascript.org/show_bug.cgi?id=1908#c2) is problematic, as a
property name blacklisted by an `@@unsopables` anywhere on the prototype
chain will also be blacklisted
On 21 May 2014 14:33, Claude Pache claude.pa...@gmail.com wrote:
I have thought about the right semantics (and the issues) of the existential
operator.
user.getPlan?().value?.score;
The intended semantics of `?` is that, whenever its LHS evaluates to `null`
or `undefined`,
the
Apparently, there has been a semantic change between ES5 and ES6
regarding assignment to wrapper objects in strict mode. That is,
'use strict'; .x = 0
would throw in ES5, but AFAICS, no longer does in ES6. Was this change
discussed? What is the rationale?
(FWIW, current implementations
On 28 May 2014 13:41, André Bargull andre.barg...@udo.edu wrote:
Apparently, there has been a semantic change between ES5 and ES6
regarding assignment to wrapper objects in strict mode. That is,
'use strict'; .x = 0
would throw in ES5, but AFAICS, no longer does in ES6. Was this change
On 28 May 2014 14:08, André Bargull andre.barg...@udo.edu wrote:
On 5/28/2014 2:00 PM, Andreas Rossberg wrote:
On 28 May 2014 13:41, André Bargull andre.barg...@udo.edu wrote:
Apparently, there has been a semantic change between ES5 and ES6
regarding assignment to wrapper objects in strict
On 4 June 2014 00:12, John Lenz concavel...@gmail.com wrote:
No I intentionally used let. This is not legacy code (I shouldn't have
use the word existing) but new sloppy mode code that would like the code
to be block scoped.
Why would you want to write new sloppy mode code, though? Honest
On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places you
need it (using eval to introduce new symbols into global scope).
You don't necessarily need sloppy mode for that. In strict mode, you
can still express it as
On 5 June 2014 16:08, John Barton johnjbar...@google.com wrote:
On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg rossb...@google.com
wrote:
On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places
you
need
C-style for-loops allow declarations as init statements, but only some
of them. Yet, the others (function and class) are actually
syntactically legal in that position as well, because they are simply
parsed as expressions. Consider:
let x = 0
for (let x = 1; ;) x // 1
for (const x = 1; ;)
On 5 June 2014 17:44, John Lenz concavel...@gmail.com wrote:
That is to say, is this valid:
if (x) {
f();
function f() { doSomething() }
}
The same question applies to class declarations. I assume that top level
class declarations hoist. (Where is this in the spec?)
Yes, that is
with making
that change as well, on the grounds that it is more regular.
/Andreas
However, I agree that banning these is much less surprising than allowing
them as expressions rather than declarations.
On Thu, Jun 5, 2014 at 7:58 AM, Andreas Rossberg rossb...@google.com
wrote:
C-style
the
language to make such things illegal.
The point is not so much that it is pointless or nonsensical, but that
it has surprising and arguably inconsistent meaning.
/Andreas
On Jun 5, 2014, at 7:58 AM, Andreas Rossberg rossb...@google.com wrote:
C-style for-loops allow declarations as init
On 11 June 2014 18:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Other than the Array.of and Array.from usages the other uses are all
necessary either functionally (you can't just try to construct by calling
[[Construct]], it requires an explicit guard) or to deal with special
On 13 June 2014 12:33, Tom Van Cutsem tomvc...@gmail.com wrote:
One important detail:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
new C(...args) = C.apply(C[Symbol.create](), args)
I prefer Jason's transformation for the following reason: imagine a
On 13 June 2014 18:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We could consider special cases loop bodies that are BlockStatements and
statically reject those that contain declaration that shadow the loop
declarations. However, I think it is probably best to leave that sort of
On 18 June 2014 09:40, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
## Benefits
* As with Allen's proposal, we would drop [[Construct]] and the
`construct`
trap.
* @@create can be dropped
Some observations:
* I think the 'import * as x' syntax for module imports is not an
improvement, for at least two reasons:
- It raises the expectation that you can actually write 'import *
from' (as already noted in this thread).
- It removes the syntactic marker for binding a module
On 27 June 2014 18:36, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg rossb...@google.com
wrote:
- It removes the syntactic marker for binding a module identifier.
That is problematic because (a) module identifiers come with extra
static
On 27 June 2014 17:32, Kevin Smith zenpars...@gmail.com wrote:
So to me the path forward is clear: we keep real modules, axe the default
feature, and take a temporary hit of dissatisfaction from existing users so
that we can expand the JS user base.
Note that the other half of my argument was
On 27 June 2014 21:26, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg rossb...@google.com
wrote:
I think you are missing the central problem. If imports/exports are to
be statically checked, then module bindings, their exports, and their
uses
On 28 June 2014 20:23, Rick Waldron waldron.r...@gmail.com wrote:
On Saturday, June 28, 2014, Brendan Eich bren...@mozilla.org wrote:
Ok, nerdbait -- but I'll take it and champion it at the next TC39 meeting.
Thanks,
Yes, if you hadn't I would've :)
I doubt there will be an opposition, but
On 27 June 2014 21:45, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg rossb...@google.com
wrote:
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
On 30 June 2014 19:01, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Jun 30, 2014 at 10:27 AM, Jan Keromnes j...@mozilla.com wrote:
I'd just like to add that joke requests like Math.TAU that have no
place in the language specification itself generate a considerable
amount of overhead for
On 30 June 2014 19:01, C. Scott Ananian ecmascr...@cscott.net wrote:
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg rossb...@google.com
wrote:
...this is why I've been arguing strongly for consistent syntax
regardless.
Static checking and lazy binding should be value added features
ES6 will have block scoping. However, it turns out that there are at
least two different forms of blocks in the language:
- normal block statements
- block-like bodies hardwired into other constructs (try/catch bodies,
function bodies)
In the current draft spec, these come with different rules
On 16 July 2014 18:38, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
(Note that this topic is on the agenda for this month's TC39 meeting)
Unfortunately, I won't be at the meeting. Do you think we can afford
to defer this until September?
(Also, note that as far as I can tell, the
On 17 July 2014 19:29, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
On 16 July 2014 18:38, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
(Note that this topic is on the agenda for this month's TC39 meeting)
Unfortunately, I won't be at the meeting. Do you think we can
On 31 July 2014 00:05, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
I think this subtle discrepancy is both unfortunate and unnecessary
[1]. Moreover, with ES7 do expressions, I would like it to hold that
(...) = {...}≡(...) = do {...}
I channeled you as best
On 10 September 2014 16:45, Erik Arvidsson erik.arvids...@gmail.com wrote:
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning up the
On 10 September 2014 16:52, Mark S. Miller erig...@google.com wrote:
On Wed, Sep 10, 2014 at 7:45 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
I see two options here.
1. Add IteratorClose to all places in the spec where we use iterators.
Why was #1 rejected? I just don't remember.
I
On 10 September 2014 17:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it exhausts its generator. See
On 12 September 2014 17:18, Mark S. Miller erig...@google.com wrote:
Even when written explicitly, either by an IDE or a human, the
constructor(a, b, c) {
this = new super(...arguments);
...
}
pattern is usually bad. It is fine in a certain special case I mention
below. It would
where
people pass redundant arguments to functions -- _that_ is bad
practice. The language shouldn't default to that practice itself.
On Sep 12, 2014, at 8:26 AM, Andreas Rossberg wrote:
I think it's fine to have a default new super call, but only with an
empty argument list. That would also
On 15 September 2014 06:24, Brendan Eich bren...@mozilla.org wrote:
In the C++ family (Andreas is right, there's a history and lineage to
consider), the special head form may require you to keep it simple and put
any such conditioning in the base class, or an intermediary. This doesn't
bite
On 17 September 2014 19:04, Brendan Eich bren...@mozilla.org wrote:
I agree with Domenic that any derived-class constructor that needs to
allocate with specific arguments *and* that must distinguish new'ing from
calling should have to write an if-else. That's a hard case, EIBTI, etc.
I agree.
On 17 September 2014 19:24, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/17/14, 1:15 PM, Andreas Rossberg wrote:
In the light of that, I'm stilling missing the
compelling reason to introduce new^ at all.
Say you have:
class A extends B {
constructor() {
this = new super
On 15 September 2014 19:20, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
Want to safe the colon for type annotations.:)
Someone building a compile-to-JS language (not LLJS) pointed out to me what
LLJS already did: C-style `type declarator` annotations
On 28 September 2014 20:34, Michał Wadas michalwa...@gmail.com wrote:
We have Object.observe (asynchronous callback whenever object
properties changes), but do we need Function.observe (asynchronous
callback whenever function is called)?
Cons:
- can prevent many optimizations (but
On 28 September 2014 17:01, Marius Gundersen gunder...@gmail.com wrote:
The stacktrace should probably be an array of objects with the properties
`filename`, `function`, `line` and `column`.
Just to be clear, since you said array of objects: 'function' would
still have to be string-valued, to
On 29 September 2014 18:06, Filip Pizlo fpi...@apple.com wrote:
- JS is a great language; it actually lets you write an honest loop. You
don’t *need* tail calls.
Let me repeat what I just wrote in my previous mail: I think not
enough people appreciate the (substantial) difference between
On 29 September 2014 16:55, John Lenz concavel...@gmail.com wrote:
On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com wrote:
On Sep 27, 2014, at 10:15 PM, John Lenz concavel...@gmail.com wrote:
I would like to get see stack traces standardized for ES7, to that end,
I would
On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
That's why, IIRC (haven't checked lately), TCO is only specified for calls
from non-sloppy functions.
PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from
what I know (corrections
Boris' point seems to be -- and I agree -- that such a test would only
be a semi-decision procedure. I.e., it can only falsify, but not
validate the property for the test program.
/Andreas
On 30 September 2014 04:48, Brendan Eich bren...@mozilla.org wrote:
Put it in a worker or node.js. The
On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote:
I just realized this has an unfortunate implication for REPLs. Suppose
you make this typo:
js let x = Math.cso(a)// oops, TypeError, should be Math.cos
Now x is irreparably hosed in your REPL. That seems
On 30 September 2014 16:31, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg rossb...@google.com wrote:
On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
That's why, IIRC (haven't checked lately), TCO
On 30 September 2014 22:38, David Herman dher...@mozilla.com wrote:
On Sep 30, 2014, at 4:03 AM, Andreas Rossberg rossb...@google.com wrote:
On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com
wrote:
I just realized this has an unfortunate implication for REPLs. Suppose
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a
full parse of the function.
Well, it is no harder than reporting reference
On 1 October 2014 20:32, Jason Orendorff jason.orendo...@gmail.com wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function f(value) { x = value; }
On 2 October 2014 09:24, Andreas Rossberg rossb...@google.com wrote:
On 1 October 2014 20:32, Jason Orendorff jason.orendo...@gmail.com wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script
On 2 October 2014 10:45, Mark Miller erig...@gmail.com wrote:
On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg rossb...@google.com
wrote:
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
On 2 October 2014 16:06, Andreas Rossberg rossb...@google.com wrote:
So, yes, please let us remove the requirement to make const
assignments an early error. A single, relatively unimportant
diagnostics like that is not worth the considerable complication for
VMs, especially given that all
On 2 October 2014 17:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I believe that the module champions have always wanted static unresolvablse
reference rejection to be part of the module semantics. But we've never had
actual specification for that semantics.
Yes, I had always hoped
On 5 October 2014 17:51, Brian Di Palma off...@gmail.com wrote:
1) I think you mean that a parser wants to fail quickly if it comes
across an identifier that was not previously declared as an import but
that could be declared as one deeper in the module file? The simple
solution to that
On 8 October 2014 14:11, Brian Di Palma off...@gmail.com wrote:
I didn't realize how limited in power these fast parsers actually
were, they are basically lexers.
No, that's not correct. They have to perform a full syntax check. That
does not imply binding analysis, though, which is usually
On 21 October 2014 22:31, Mark S. Miller erig...@google.com wrote:
in saying that [weak maps] are not designed to work efficiently in that
manner.
Actually, they are. The problem is that initial implementations date from
before we appreciated the need for the transposed representation. The
On 22 October 2014 14:18, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
FWIW the Multiple WeakMaps approach seems to be 2X ( Chrome ) up to 3X ( FF
Nightly ) faster than single WeakMap approach but I don't know how much
WeakMap instances cost in terms of GC operations so this bench might
On 24 October 2014 22:13, Mark S. Miller erig...@google.com wrote:
On Fri, Oct 24, 2014 at 4:19 AM, Andreas Rossberg rossb...@google.com
wrote:
On 22 October 2014 16:45, Mark S. Miller erig...@google.com wrote:
On Tue, Oct 21, 2014 at 11:59 PM, Andreas Rossberg rossb...@google.com
wrote
While polishing some remaining corners of lexical scoping support in
V8, we stumbled over the following.
ES5 has the invariant that any identifier not found on the scope chain
_has to be_ a property of the global object (except in the presence of
'with' or sloppy direct eval), or be a reference
On 29 October 2014 02:48, Isiah Meadows impinb...@gmail.com wrote:
I'm proposing simply initializing a new instance and GC'ing the old
instance entirely (updating the `this` to point to the new) instead of
the current algorithm of maintaining a list of keys. I know that it
potentially slow
On 28 October 2014 17:38, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Also I'll check if it's feasible to make it a runtime error for a global let
to shadow a non configurable property of the global object.
Is there a reason why we cannot make it an error for any present
property? Maybe
On 28 October 2014 23:22, Jeff Walden jwalden...@mit.edu wrote:
On 10/28/2014 09:10 AM, Andreas Rossberg wrote:
If so, how do we fix this? Allowing shadowing after the fact is pretty
bad, since it will probably make all accesses to builtin globals
slower in ES6. But it is particularly bad
On 27 October 2014 16:50, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-10-27 15:00 GMT+01:00 Andreas Rossberg rossb...@google.com:
but without breaking membrane transparency.
I'm still not sure I understand how this affects membranes
specifically. A membrane would never pass a proxied
On 27 October 2014 17:45, Mark S. Miller erig...@google.com wrote:
On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg rossb...@google.com
wrote:
On Wed, Oct 22, 2014 at 2:26 PM, Mark Miller erig...@gmail.com wrote:
[...] When the WeakMap is known to necessarily live longer than its
keys
On 29 October 2014 21:59, Mark S. Miller erig...@google.com wrote:
On Wed, Oct 29, 2014 at 8:16 AM, Andreas Rossberg rossb...@google.com
wrote:
On 27 October 2014 16:50, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-10-27 15:00 GMT+01:00 Andreas Rossberg rossb...@google.com:
but without
On 29 October 2014 22:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 29, 2014, at 4:13 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
Don't forget the implications for the future. If declaring certain
names in top level scopes is an error if they are also present in the
global
On 31 October 2014 16:40, Katelyn Gadd k...@luminance.org wrote:
I'd also like to chime in since this is a real problem for
performance-sensitive JSIL code:
The idea that JS runtimes will just optimize all our
performance-sensitive loops is lovely. It also appears to be a
fantasy, because
On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
This change would only make sense if we also were to special-case all
other places in the spec that currently say if O is an exotic Array
On 13 November 2014 12:25, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a footgun to
On 17 November 2014 17:29, Alex Kocharin a...@kocharin.ru wrote:
17.11.2014, 03:07, “Biju” bijumaill...@gmail.com:
I wish, I could write elegant two of the code pattern I use frequently.
[...]
Patten 2.
I do like to code functions with early exit, like
function someValidationProcess(){
The discussion here still makes various untested assumptions about the
transposed representation. With respect to .clear in particular, it
seems to assume that this representation does not normally need the
ability to iterate (internally) over the keys of a weak map. AFAICT,
that is incorrect.
WeakMap
)
https://github.com/WebReflection/es6-collections#the-weakmap-is-not-weak--and-why
On Thu, Nov 27, 2014 at 9:17 AM, Andreas Rossberg rossb...@google.com
wrote:
The discussion here still makes various untested assumptions about the
transposed representation. With respect to .clear
On 27 November 2014 at 15:58, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
On Thu, Nov 27, 2014 at 2:44 PM, Andreas Rossberg rossb...@google.com
wrote:
Well, there is no functionally correct polyfill for WeakMaps that is
actually weak, regardless of .clear.
Please bear with me so I
On 27 November 2014 at 19:40, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Nov 27, 2014, at 1:17 AM, Andreas Rossberg wrote:
The discussion here still makes various untested assumptions about the
transposed representation. With respect to .clear in particular, it
seems to assume
On 1 December 2014 at 03:12, Mark S. Miller erig...@google.com wrote:
On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Per spec ES6, it seems to me like attempting to define a non-configurable
property on a WindowProxy should throw and getting a property descriptor for
a
On 29 November 2014 at 22:30, Mark S. Miller erig...@google.com wrote:
On Fri, Nov 28, 2014 at 4:21 AM, Andreas Rossberg rossb...@google.com wrote:
[...]
With a normal ephemeral weak map implementation, like the one in V8,
the value in a (map,key,value) triple can be reclaimed _immediately_
On 2 December 2014 at 19:15, Mark S. Miller erig...@google.com wrote:
In both minor or major collection both m and v are immediately
reclaimed, because neither is strongly reachable at that point
which shows the asymmetry, and that v8 is effectively optimizing for
the wrong side of that
On 3 December 2014 at 23:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
See https://bugs.ecmascript.org/show_bug.cgi?id=3383
The issue concerns things like this:
don't use strict;
var x=outer
function f(a=eval( var x=1; 42),
x=eval( console.log(can+(x!=1?'t:)+ see
On 4 December 2014 at 00:54, David Bruant bruan...@gmail.com wrote:
The way I see it, data structures are a tool to efficiently query data. They
don't *have* to be arbitrarily mutable anytime for this purpose.
It's a point of view problem, but in my opinion, mutability is the problem,
not
On 4 December 2014 at 13:58, David Bruant bruan...@gmail.com wrote:
Le 04/12/2014 09:55, Andreas Rossberg a écrit :
On 4 December 2014 at 00:54, David Bruant bruan...@gmail.com wrote:
The way I see it, data structures are a tool to efficiently query data.
They
don't *have* to be arbitrarily
On 6 February 2015 at 10:19, Jordan Harband ljh...@gmail.com wrote:
Should a JS engine retain a reference to the original value of well-known
symbols (like Symbol.iterator), or should steps that use
well-known-Symbol-valued properties (like for..of iteration) always do a
dynamic lookup on
On 21 January 2015 at 01:28, Mark S. Miller erig...@google.com wrote:
* Pages are created by people who don't really understand the code they
are modifying, nor the semantics of the language it is written in. They
simply keep fiddling with it until it no longer seems to be broken, and
then
On 20 January 2015 at 20:26, Mark S. Miller erig...@google.com wrote:
On Tue, Jan 20, 2015 at 10:05 AM, Brendan Eich bren...@mozilla.org
wrote:
Domenic Denicola wrote:
Nominal-typing bad!
That X-typing bad! line is not helpful. (What is this, a sports/beer
commercial?)
Even structural
On 20 January 2015 at 23:25, Brendan Eich bren...@mozilla.org wrote:
Ryosuke Niwa wrote:
Having said that, TDZ was introduced to give let, const, and alike a
sensible behavior as I understand it. Since this was never defined by
let or const, it seems a little arbitrary and inconsistent to
On 15 February 2015 at 12:07, Katelyn Gadd k...@luminance.org wrote:
I'm certainly in favor of VMs improving to handle that, and adding
pressure for it is good. However, optimizing a TypedArray temporary
arg to .set() is a much simpler problem than doing the escape analysis
necessary to be
at all?
Frozen value null? I don't understand. You'd get the actual values from...
where?
/Andreas
On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg rossb...@google.com
wrote:
On 15 February 2015 at 12:07, Katelyn Gadd k...@luminance.org wrote:
I'm certainly in favor of VMs improving
On 28 January 2015 at 13:14, Claude Pache claude.pa...@gmail.com wrote:
To me, finite is just to be taken in the common mathematical sense of
the term; in particular you could have theoretically a string of length
10^1. But yes, it would be reasonable to restrict oneself to strings of
On 27 February 2015 at 15:22, Andri Möll an...@dot.ee wrote:
noone? JSLint doesn't even let you write a for/in loop if you don't have
`obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
properties (included methods from old classes/ahem prototypes) reassigned
everywhere.
On 27 February 2015 at 16:16, Andri Möll an...@dot.ee wrote:
The fragile base class problem is one.
That’s a problem of the caller, not the callee, the user of Object.assign.
If I decide to use inheritance, that’s my risk.
You would like it to be that way, but that's not how it plays out
On 5 March 2015 at 04:57, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
This is novel weirdness.
In C++/Java/C# etc. you don't see it because the corresponding
declarations create immutable bindings. I agree that it would have been
nice of we could have done that.
For the record, I strongly dislike the function behaviour. Turning a
function expression into a declaration silently changes the meaning of
internal recursive references, in ways that many people find very
surprising. That is an unnecessary pitfall.
Your argument essentially is that you want to
On 23 February 2015 at 10:37, David Bruant bruan...@gmail.com wrote:
Le 23/02/2015 10:10, Michał Wadas a écrit :
Cloning objects is long requested feature.
clone object javascript yields 1 480 000 results in Google.
I'd like to share this as an answer
On 23 February 2015 at 16:22, Mark S. Miller erig...@google.com wrote:
We still an an option open to us, that would merely compatibly remove a
restriction from the language rather than add a feature: Allow labels to
remain visible across function boundaries, or at least across arrow
function
I agree that we should have wildcard patterns. I also think that array
elisions are a non-solution, because you need a magnifier to read or count
them, and they square oddly with optional commas in the end.
/Andreas
On 29 April 2015 at 13:47, Elie Rotenberg e...@rotenberg.io wrote:
Wow,
On 29 April 2015 at 02:21, John Lenz concavel...@gmail.com wrote:
I missed it, thanks.I know things will improve in time but I'm just
coming from a discussion with folks complaining about the performance of
generators and GC overhead in real code with Chrome and Firefox relative to
simple
On 29 April 2015 at 18:37, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
On 29 April 2015 at 02:21, John Lenz concavel...@gmail.com mailto:
concavel...@gmail.com wrote:
I missed it, thanks.I know things will improve in time but I'm
just coming from
On 16 April 2015 at 11:34, Michael Ficarra mfica...@shapesecurity.com
wrote:
ES2015 section 19.2.3.5 (Function.prototype.toString) places four
restrictions on the output of Function.prototype.toString, one of which is
If the implementation cannot produce a source code string that meets these
601 - 700 of 778 matches
Mail list logo
