On Oct 24, 2014, at 9:11 AM, Brendan Eich wrote:
André Bargull wrote:
IE11 moves elements up one index, throws a RangeError and completes
instantly (no hang or oom).
Per spec, huzzah -- but the spec needs fixing.
That conclusion isn't so obvious to me. The current algorithms for the
I can only answer briefly right now: This is intentional. Array instances are
still limited to 2^32-2 elements. Compat issues to change. But, the generic
array methods aren't restricted to Array instances and support larger lengths
in those cases.
___
that level of detail.
Allen
On Oct 23, 2014, at 5:44 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I can only answer briefly right now: This is intentional. Array instances
are still limited to 2^32-2 elements. Compat issues to change. But, the
generic array methods aren't restricted to Array
On Oct 19, 2014, at 1:04 PM, Rick Waldron wrote:
On Sun, Oct 19, 2014 at 1:59 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
A file that is imported is treated as a module. That's it.
And you can statically infer that a file is module by reading the source and
scanning for
On Oct 19, 2014, at 2:28 PM, Mark Volkmann wrote:
On Sun, Oct 19, 2014 at 4:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
It is implementation dependent how it is determined whether an individual
file will be parsed as a Script or as a Module.
This seems problematic because
On Oct 19, 2014, at 5:42 PM, Mark Volkmann wrote:
Can we say anything more concrete if we restrict the discussion to modern
browsers as opposed to non-browser ES engines? Is it fair to say that in
those environments a file will always be treated as a module if it is
imported by another
On Oct 17, 2014, at 12:52 AM, Claude Pache wrote:
Le 17 oct. 2014 à 08:54, Isiah Meadows impinb...@gmail.com a écrit :
I was more looking for the rationale behind it. I know it currently
doesn't hoist.
In the discussion pointed by Domenic, it is explained why classes don't hoist
On Oct 16, 2014, at 5:31 PM, Boris Zbarsky wrote:
On 10/16/14, 5:58 PM, Brendan Eich wrote:
Can you say more?
Vats as currently specified have independent event loops and allow parallel
JS execution, in the sense that they are totally disconnected from each other
and have separate
On Oct 16, 2014, at 11:27 AM, Erik Arvidsson wrote:
Seems reasonable but it is too late to make any changes to ES6.
I agree, but it's possible to propose extending Set,prototype with additional
methods.
For example an 'addB' method that is similar to 'add' but returns a Boolean
result.
On Oct 14, 2014, at 7:50 PM, Boris Zbarsky wrote:
On 9/26/14, 10:03 PM, Boris Zbarsky wrote:
2) Say someone runs this in a web page:
(function f() Promise.resolve().then(f))()
what should happen when the user navigates away from that web page and why?
Given the lack of response
On Oct 15, 2014, at 12:14 PM, Boris Zbarsky wrote:
On 10/15/14, 3:05 PM, Allen Wirfs-Brock wrote:
...
So, the basic question becomes one how the browser maps web pages to
Vats. If each pages get a separate Vat
They don't. Basically, same-origin web pages correspond to multiple Realms
On Oct 15, 2014, at 1:36 PM, Boris Zbarsky wrote:
On 10/15/14, 3:45 PM, Allen Wirfs-Brock wrote:
...
A PromiseReactionJob that is associated with a marked Realm
Are PromiseReactionJobs associated with a Realm at all? If so, how is that
Realm determined?
Every PendingJob [1] has has
On Oct 15, 2014, at 1:34 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
realms and vats and ES jobs.
I like mixed metaphors as much as the next person, but srsly, can we talk?
Realm : Quest :: ??? : Job
Vat : Realm :: WindowProxy : Window
I'm not sure of these, help wanted fixing
s/connivance/ conveyance/
On Oct 15, 2014, at 2:18 PM, Allen Wirfs-Brock wrote:
On Oct 15, 2014, at 1:34 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
realms and vats and ES jobs.
I like mixed metaphors as much as the next person, but srsly, can we talk?
Realm : Quest
ES6 Draft 29,
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#october_14_2014_draft_rev_28
This includes the major work items from the September TD39 meeting.
Changes include:
Removed loader pipeline and Reflect.Loader API (functionality being transfered
to sperate
An old discussion. See:
https://esdiscuss.org/topic/set-and-map-additions-in-the-latest-draft
https://esdiscuss.org/notes/2012-07-26 (section heading: Map and Set methods:
conclusion)
https://bugs.ecmascript.org/show_bug.cgi?id=591
Allen
On Oct 10, 2014, at 4:12 PM, Rick Waldron wrote:
Yes. Already in my working draft.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Oct 3, 2014, at 7:35 AM, Rick Waldron wrote:
On Fri, Oct 3, 2014 at 10:04 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
Number has always been able to handle the full NumericLiteral. In ES5.1 it
can handle '-1', '-0', '0xff', '0XFF', '1e2', '-1E-2', 'Infinity'. Breaking
that
On Oct 1, 2014, at 7:09 AM, Erik Arvidsson 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.
I think we need to either enforce this or remove this
On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote:
...
I was with you until you got to the following point
If there is an intervening with or sloppy direct eval, then there is not a
statically apparent assignment to a const variable. Since this can only occur
in sloppy code anyway, it
. Sloppy with or eval
dynamically shadowing a sloppy a [[Set]] reference to a const binding. Can't
be a early error, should be a runtime error.
Allen
On Wed, Oct 1, 2014 at 8:59 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote
On Oct 1, 2014, at 9:43 AM, Oliver Hunt wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller erig...@google.com wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert that
On Oct 1, 2014, at 10:30 AM, Mark Miller wrote:
On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime
On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote:
My original response questions were poorly asked. I understand the TDZ
semantics, but I couldn't reproduce anything meaningful from your original
example, because I don't have the SpiderMonkey build that includes the let
updates
On Sep 29, 2014, at 9:23 AM, Mark S. Miller wrote:
Although we would both like to see function.caller gone as well, we are also
both much more skeptical that this is possible. Let's assume that it is not.
The conclusion that follows is only that sloppy calls to sloppy functions
can't be
On Sep 29, 2014, at 11:00 AM, Mark S. Miller wrote:
Agreed. TCO or PTC specified only for strict mode functions, not for all
non-sloppy functions.
Would be nice to extend this at least to bound functions resulting from
binding a strict function, but too late to consider for ES6. In any
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P
On Sep 29, 2014, at 1:13 PM, Mark S. Miller wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote:
On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics
TDZ
On Sep 29, 2014, at 2:14 PM, Rick Waldron wrote:
On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that
loads and runs this script:
throw 0;
let x;
This leaves the
On Sep 29, 2014, at 3:37 PM, Jason Orendorff wrote:
On Mon, Sep 29, 2014 at 4:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote:
Function.prototype.apply, Function.prototype.call, and Reflect.apply
currently call PrepareForTailCall
On Sep 18, 2014, at 11:29 AM, Dmitry Lomov wrote:
You haven't specified the constructor body, I assume you have intentionally
omitted it, and in that case the above is equivalent to
class A extends HTMLElement {
constructor() {
this = new super();
}
}
There is no
of course! I don't know why my brain wiring keeps producing this^.
Allen
On Sep 18, 2014, at 1:28 PM, Dmitry Lomov wrote:
On Thu, Sep 18, 2014 at 10:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 18, 2014, at 1:11 PM, Domenic Denicola wrote:
From: es-discuss
On Sep 18, 2014, at 1:30 PM, Domenic Denicola wrote:
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
But that won't give you a real HTMLElement exotic object, if there is such a
thing, and won't initialize it properly.
But you can get around that problem if the HTMLElement
On Sep 18, 2014, at 2:04 PM, Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@mozilla.org]
So are you withdrawing your variation (option 3 or whatever it is)? Not
advocating, just asking (trying to keep up!).
Since nobody else seems to be fighting for it, and I am highly
On Sep 16, 2014, at 11:22 PM, Brendan Eich wrote:
Jussi Kalliokoski wrote:
Unicode flag disabling features to enable parallelism is another footnote
for WTFJS.
A bit overdone, but I agree on this point.
A separate flag per regexp, and/or a way to opt-out of RegExp.$foo
altogether,
On Sep 17, 2014, at 8:59 AM, Andrea Giammarchi wrote:
FWIW that 's' flag would work for me, but about not being specd, those
properties are described already here:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getreplacesubstitution
that doesn't say anything about RegExp
)
actually I did respond:
On Sep 15, 2014, at 11:24 AM, Allen Wirfs-Brock wrote:
On Sep 14, 2014, at 8:48 PM, Kevin Smith wrote:
It seems to me that with the proposed design we're going to have to branch
on new^ continually: if we don't, then the function will always fail
On Sep 17, 2014, at 6:17 AM, Herby Vojčík wrote:
Claude Pache claude.pa...@gmail.comnapísal/a:
For instance, if I wanted to support to be called through the legacy
`SuperConstructor.call(this, ...args)` trick in addition to be new’d, I'd
rather try the following:
On Sep 17, 2014, at 6:39 AM, Kevin Smith wrote:
constructor(x, y) {
if (new^)
this = new super(x);
else
super.constructor(x);
this.y = y;
}
The point here is that the purpose of the constructor method is not only
allocation,
On Sep 17, 2014, at 7:24 AM, Kevin Smith wrote:
That's not true, is it? Assuming someone (e.g. B) actually assigns a property
of `this`, an error will occur (or worse, a global will be created, in sloppy
mode).
Sorry, when I say called, I mean called with a proper this variable.
On Sep 17, 2014, at 7:29 AM, Claude Pache wrote:
Le 11 sept. 2014 à 18:35, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
These two Gist have parallel construction for easy comparison. I suggest
approaching this is by first readying through one of the Gists and then
doing a side
On Sep 17, 2014, at 10:15 AM, Andreas Rossberg wrote:
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
On Sep 17, 2014, at 10:50 AM, Erik Arvidsson wrote:
I still feel like Kevin's point has not yet been resolved. How can we make
this work with today's patterns?
import {C} from './C.js';
function D() {
C.call(this);
}
D.prototype = {
__proto__: C.prototype,
constructor: D,
Correction below: s/this\^/new\^/
On Sep 17, 2014, at 12:19 PM, Allen Wirfs-Brock wrote:
On Sep 17, 2014, at 10:50 AM, Erik Arvidsson wrote:
I still feel like Kevin's point has not yet been resolved. How can we make
this work with today's patterns?
import {C} from './C.js
On Sep 15, 2014, at 5:10 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
But feel free to propose and champion a complete alternative propos that
address all aspects of object instantiation design. That's probably a better
approach than trying to incrementally change details
On Sep 16, 2014, at 6:52 AM, Claude Pache wrote:
Le 15 sept. 2014 à 04:47, Domenic Denicola dome...@domenicdenicola.com a
écrit :
I think I'd most be in favor of a third option that implicitly adds `this =
Object.create(new^.prototype)` if no `this`-assignment is present. That way,
On Sep 16, 2014, at 11:16 AM, Domenic Denicola wrote:
I had a conversation with Jaswanth at JSConf EU that revealed that RegExps
cannot be used in parallel JS because they modify global state, i.e.
`RegExp.$0` and friends.
We were thinking it would be nice to find some way of getting rid
On Sep 16, 2014, at 12:57 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We have long standing consensus on the current ES6 class design and that
includes a `super()` constructor call that can be arbitrarily placed within
the constructor body.
I'm ok with consensus if it's real
On Sep 14, 2014, at 9:24 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
the C/C# constructor header approach butts heads with other ES features and
isn't expressive for the sort of dynamic classes that ES allows.
In terms of headbutting, consider
`constructor({a: x, b: y), [a1,a2,a3
On Sep 14, 2014, at 8:48 PM, Kevin Smith wrote:
Would this work?
class C extends B {
constructor(a, b, c) : super(...gimmeSomeComplexSuperArgsYo(a, b, c))
{
// ...
}
}
Or using static helper methods, if you prefer:
class C extends B {
On Sep 14, 2014, at 7:47 PM, Domenic Denicola wrote:
I want to give a +1 to Allen. The syntax really is
what-you-see-is-what-you-get, which is a great virtue. The C++-derived
initializer is cute and tempting, but not nearly as powerful or easy to grok.
That said, I feel weakly that
On Sep 12, 2014, at 8:55 PM, Erik Arvidsson wrote:
On Sep 12, 2014 6:39 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Thu, Sep 11, 2014 at 4:15 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
`new^` is lexically scoped, just this `this` and `super`. If an arrow
On Sep 14, 2014, at 5:27 PM, Rick Waldron wrote:
As a follow up to these comments re: `this = new super(x, y);`, I couldn't
find anything in this thread or the gists that discussed how, if at all,
`super` syntax or semantics will change in method bodies.
See the third file in each of
On Sep 14, 2014, at 6:01 PM, Rick Waldron wrote:
On Sun, Sep 14, 2014 at 8:51 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 14, 2014, at 5:27 PM, Rick Waldron wrote:
As a follow up to these comments re: `this = new super(x, y);`, I couldn't
find anything
On Sep 14, 2014, at 4:23 PM, Brendan Eich wrote:
Kevin Smith wrote:
If we want to merge allocation with initialization, then I'm going to want
to invoke C# (yet again):
class ColoredPoint extends Point {
constructor(x, y, color) : super(x, y) {
this.color = color;
On Sep 11, 2014, at 11:39 PM, Jeff Morrison wrote:
If a constructor body contains an assignment of the form this = then
automatic allocation is not performed and the constructor is expected to
perform manual allocation.
If I'm understanding this correctly, this means that snippet (A)
On Sep 12, 2014, at 8:01 AM, Kevin Smith wrote:
Sorry to interject, but was the rationale for needing a new syntax for this
(vs. an API-based solution) presented anywhere? I can't seem to find it.
Feel free to correct me here...
The current setup (with @@create) was designed to
On Sep 12, 2014, at 8:18 AM, Mark S. Miller 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 be a disaster
On Sep 12, 2014, at 8:26 AM, Andreas Rossberg wrote:
Thanks Mark, this was exactly my concern as well. In general, it is
bogus to assume that the parameter lists of a base and a derived
constructor bear any relation. And even if they happen to do so today,
they might no longer tomorrow,
On Sep 12, 2014, at 4:22 AM, Claude Pache wrote:
Le 12 sept. 2014 à 08:39, Jeff Morrison lbljef...@gmail.com a écrit :
That is satisfying for most cases while remaining backward compatible with
ES1-5, but it is a priori problematic in the following situations, where one
may want
On Sep 11, 2014, at 1:05 AM, Brendan Eich wrote:
The tag goes at the front. What's missing from the design that can't be
provided as a standard exported deindent function?
exactly:
var a = dontIndent
`This is a template string.
Even though each line
At the last TC39 meeting (
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#44-instantiation-reform-review-create-design-rationale-and-possible-alternatives
and
On Sep 10, 2014, at 6:24 PM, Boris Zbarsky wrote:
On 9/10/14, 5:48 PM, Allen Wirfs-Brock wrote:
Why not just us ES as the specification language for most things in the
WebIDL world? Or if not full ES, a simplified form Spec-ES.
There are a few issues with using ES for specifying Web IDL
oh oops! they are supposed to be new^. Will fix...
On Sep 11, 2014, at 12:55 PM, Boris Zbarsky wrote:
On 9/11/14, 12:35 PM, Allen Wirfs-Brock wrote:
https://gist.github.com/allenwb/291035fbf910eab8e9a6 summaries the
main syntactic changes since the meeting and provides rationales them
On Thu, Sep 11, 2014 at 3:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
oh oops! they are supposed to be new^. Will fix...
On Sep 11, 2014, at 12:55 PM, Boris Zbarsky wrote:
On 9/11/14, 12:35 PM, Allen Wirfs-Brock wrote:
https://gist.github.com/allenwb/291035fbf910eab8e9a6 summaries
On Sep 11, 2014, at 3:03 PM, Brendan Eich wrote:
Ob. bikeshed: why not `new?` as the magic pair of tokens? Seems unambiguous
given `new` as a reserved identifier since dayone.
/be
new? would be fine,. Actually better. But we shied away from it, so as to
not impinge upon future use of
On Sep 11, 2014, at 2:59 PM, Brendan Eich wrote:
Claude Pache wrote:
Recently, `String(symbol)` has been modified in order to not throw, on the
ground that it is an explicit conversion, and a safer one than
`.toString()`. [1]
And to cite the hazard, because obj[name +''] where name is a
This sounds to me like it just need to be reported as a bug There have been
previous bugs that have identified places where library methods iterated in a
manner that precluded implementing them via for-of. For example
https://bugs.ecmascript.org/show_bug.cgi?id=2083 Those bugs were all fixed.
On Sep 10, 2014, at 8:29 AM, Mark S. Miller wrote:
Hi Allen, does that mean we agreed to the equivalent of Arv's #1? If so,
great!
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
On Sep 10, 2014, at 8:44 AM, Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript. I would think you could just as easily do `.jsm` but this also
suggests that
On Sep 10, 2014, at 9:00 AM, Andreas Rossberg wrote:
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
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As soon as the language decided it would have a differentiation for modules
vs scripts then it seems only natural that it should also specify at least
some generic means of entry into one mode or another. Then it's up to
browsers or who
On Sep 10, 2014, at 9:41 AM, John Barton wrote:
On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As soon as the language decided it would have a differentiation for modules
vs scripts then it seems
On Sep 10, 2014, at 10:07 AM, Boris Zbarsky wrote:
On 9/10/14, 10:45 AM, Erik Arvidsson wrote:
1. Add IteratorClose to all places in the spec where we use iterators.
And other specs (e.g. Web IDL) that use iterators, right?
Right, or come up with some other way to say: this loop behaves as
On Sep 10, 2014, at 10:24 AM, Brendan Eich wrote:
You want aggressive common sub-expression elimination on the specs (all of
them, as bz noted).
Is there a common helper spec-only method that can be used both inside ES6
and by other specs?
Not yet. Probably should be, but I have to
On Sep 10, 2014, at 10:33 AM, Brendan Eich wrote:
Tools will have to read metadata, tea-leaves, and etheric winds to keep up.
Same as ever.
And humans. When scanning a big directly of js files it's going to be real
useful for code readers to be able to quickly identify what they are
On Sep 10, 2014, at 10:37 AM, Boris Zbarsky wrote:
On 9/10/14, 1:28 PM, Allen Wirfs-Brock wrote:
Right, or come up with some other way to say: this loop behaves as if it
was implemented using for-of.
Thing is, for my Web IDL use case I don't want _quite_ the behavior of
for-of. I want
On Sep 10, 2014, at 10:58 AM, Boris Zbarsky wrote:
On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
1. Let method be the result of CheckIterable(V).
2. ReturnIfAbrupt(method).
3. If IsCallable(method) is false, go off and do something else,
since V is not iterable.
4. Let iter
On Sep 10, 2014, at 12:41 PM, Boris Zbarsky wrote:
On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
why wouldn't a self-hoster just continue with:
for (let next of iter} {
/* body */
}
I feel like I'm missing something here.
iter is an iterator, not an iterable. So I don't think
On Sep 10, 2014, at 2:12 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 9/10/14, 4:57 PM, Domenic Denicola wrote:
Relatedly, it would be *really* nice to have a spec-level for-of, both for
ES and for web specs.
You mean so people don't have to write
Well, just for fun
const N = \n; //maybe we could find evocative unicode name.
var a = `This is a template string. ${
N}Even though each line is indented to keep the ${
N}code neat and tidy, the white space used to indent ${
N}is not
ES6 defines `Map.prototype[Symbol.toStringTag]` and
`Set.prototype[Symbol.toStringTag]` such that the ES6 version of
Object.prototype.toString will produce
[object Map] and [object Set] respectively when applied to Map or Set
instances
Allen
On Sep 4, 2014, at 2:51 PM, C. Scott Ananian
Regards
On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote:
Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that
throws a TypeError if |this| doesn't have the internal slots of a typed
On Aug 29, 2014, at 4:07 AM, André Bargull wrote:
...
We checked with the recent ES6 draft but it seems to have the same issue.
In ES6 it's actually possible to reach that step (8.1.1.2.6 GetBindingValue,
step 5), albeit it's a somewhat tricky and involves doing unusual things with
On Aug 29, 2014, at 12:10 PM, John-David Dalton wrote:
JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have settled
on using Object.prototype.toString.call as a way to determine the kind of a
value and don't expect that to throw.
This is edge case but it seems like an
On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote:
Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that
throws a TypeError if |this| doesn't have the internal slots of a typed
array. Neither %TypedArray%.prototype nor
{{Ui,I}nt{8,16,32},Float{32,64}}.prototype have these
I've thought about this a bit. I was initially inclined to agree with the idea
of extending the existing character classes similar to what Mathias' proposes.
But I now think that is probably not a very good idea and that what is
currently spec'ed (essentially that the /u flag doesn't change
On Aug 26, 2014, at 11:16 AM, Norbert Lindenberg wrote:
On Aug 26, 2014, at 10:01 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
So, here is a summary of my proposal:
3) Reserve within /u RegExp patterns, the syntax \p{characters} and
\P{characters}
This was already decided
On Aug 26, 2014, at 1:45 PM, Norbert Lindenberg wrote:
On Aug 26, 2014, at 11:15 , Mathias Bynens math...@qiwi.be wrote:
On 26 Aug 2014, at 19:01, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I see one remaining issue:
In ES5 (and ES6): `/a-z/i` does not match U+017F (ſ) or U+212A
At:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_24_2014_draft_rev_27
Fixed scoping bug in for-of, catch clause, comprehensions WRT TDZ for iteration
bindings. see bug: https://bugs.ecmascript.org/show_bug.cgi?id=3011
For-in/for-of loop bodies can’t contain tail
On Aug 22, 2014, at 7:22 AM, Kevin Smith wrote:
Also, write your echo generator this way. You have to duplicate code.
Ah, of course - thanks for reminding me.
Given something like:
function *echo() input { while (true) yield input }
It seems like what we're trying to do
On Aug 22, 2014, at 9:27 AM, Kevin Smith wrote:
and it could only be reserved in strict mode code.
I feel like I'm forgetting something obvious, but why? We already use a
parameterized grammar (not parameterized on strictness) for yield. I would
think you'd just be adding to that
On Aug 20, 2014, at 7:30 PM, Andrea Giammarchi wrote:
I like the `Function.prototype.new` hint but unless it's an implicitly
self bound method you still cannot easily pass it around as callback
for a map without binding it all over.
`arr.map(MyClass.new)` without needing to explicitly bind
On Aug 21, 2014, at 12:04 AM, Andy Wingo wrote:
On Wed 20 Aug 2014 19:55, Brendan Eich bren...@mozilla.org writes:
Kevin Smith wrote:
function *echo() input {
while (true) yield input.value;
}
So input is bound to the next() actual parameter value on each
resumption.
On Aug 21, 2014, at 9:54 AM, Brendan Eich wrote:
Andy Wingo wrote:
On Wed 20 Aug 2014 19:55, Brendan Eichbren...@mozilla.org writes:
Kevin Smith wrote:
function *echo() input {
while (true) yield input.value;
}
So input is bound to the next() actual
On Aug 21, 2014, at 10:42 AM, Allen Wirfs-Brock wrote:
On Aug 21, 2014, at 9:54 AM, Brendan Eich wrote:
Andy Wingo wrote:
On Wed 20 Aug 2014 19:55, Brendan Eichbren...@mozilla.org writes:
Kevin Smith wrote:
function *echo() input {
while (true) yield input.value
On Aug 20, 2014, at 1:11 PM, Brendan Eich wrote:
Alex Kocharin wrote:
I mean, not using `new`. JS is a functional language after all, and having a
function that can't be called as a function is weird.
Gotcha, and my point was not to mandate `new`, just allow it. I thought we
relaxed
sounds good to me, I'll update the spec. accordingly
On Aug 12, 2014, at 7:39 PM, Erik Arvidsson wrote:
symbol + '' must continue to throw.
I was suggesting that String(symbol) should not throw.
This can be spec'ed as String( value ) checking the Type of the value and
special case it in
On Aug 13, 2014, at 8:45 AM, Nathan Wall wrote:
Out of mere curiosity, why is it desired that `symbol + ''` throw?
Minimize the chance that somebody might code:
var newName = somePropertyKey+_stuff;
not realizing that somePropertyKey might be a Symbol. We don't want to
silently crete a
401 - 500 of 2846 matches
Mail list logo
