Allen mentioned that `String#at` might not make it to ES6 because nobody in
TC39 is championing it. I’ve now asked Rick if he would be the champion for
this, and he agreed. (Thanks again!)
Looking over the ‘TC39 progress’ document at
This was the method that was only useful if you pass `0` to it?
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mathias
Bynens
Sent: Friday, February 14, 2014 10:34
To: Rick Waldron; Allen Wirfs-Brock
Cc: es-discuss@mozilla.org list
Subject: Re:
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the StringIterator.
--scott
ps. I see that Domenic has said something similar.
On 14 February 2014 00:32, C. Scott Ananian ecmascr...@cscott.net wrote:
For your consideration, here is an implementation of Monadic Promises,
as a Promise subclass:
Since promises are expressible in JS you can always create a new class
that does what you want. It's also well-understood that
On 14 Feb 2014, at 11:11, Domenic Denicola dome...@domenicdenicola.com wrote:
This was the method that was only useful if you pass `0` to it?
I’ll just avoid the infinite loop here by pointing to earlier posts in this
thread where this was discussed before:
On 14 Feb 2014, at 11:14, C. Scott Ananian ecmascr...@cscott.net wrote:
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the
Yes, I know what `String#at` is supposed to do.
I was pointing out that `String#at` makes it easy to do the wrong
thing. If you do `Array.from(str)` then you suddenly have a complete
random-access data structure where you can find out the number of code
points in the String, iterate it in
I think Mathias's point, that it is exactly as useful or useless as
`codePointAt`, is a reasonable one. However,
This method is just as useful as `String.prototype.codePointAt`. If that
method is included, so should `String.prototype.at`. If `String.prototype.at`
is found not to be useful,
Can someone point me to the spec for `System.import`?
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for
On 14 February 2014 14:13, C. Scott Ananian ecmascr...@cscott.net wrote:
Can someone point me to the spec for `System.import`?
It's in the ES6 specification draft under Loader.prototype.import -
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.import
.
On 30/01/2014, at 17:13, Brendan Eich wrote:
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
On 30/01/2014, at 17:13, Brendan Eich wrote:
/
//
// Interesting!
//
// You don't want the alert to show undefined, so the extent of the inner binding in your model is the unbraced consequent of the if.
//
// That is not block scope in any plain sense.
/
How about this?
let x= 0;
if
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
On Fri, Feb 14, 2014 at 7:40 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
[...]
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com
On Fri, Feb 7, 2014 at 11:50 AM, Anne van Kesteren ann...@annevk.nl wrote:
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko
when the news broke. Mozilla can probably still make things in order
before promises hit stable.
To be clear, we fixed this. And we will be going
How about Keyword 'let' not allowed without 'use strict' or in a module. ?
On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller erig...@google.com wrote:
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
Mark S. Miller wrote:
I actually prefer #3. Given only knowledge of ES5 and of the rest of
ES6, I find it least surprising. vars hoist out of blocks. In
non-strict code, functions leak out of blocks in ways that are hard
to explain. I can understand non-strict direct eval as being
block-like,
On Fri, Feb 14, 2014 at 8:26 AM, John Barton johnjbar...@google.com wrote:
How about Keyword 'let' not allowed without 'use strict' or in a module.
?
I wish. I argued strongly that sloppy mode be maintained only to continue
to serve the purpose of being an ES3 compatibility mode, and that we
As far as I can see, your #4 and my #1 are exactly the same. How do you think
they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically considered
a
On Fri, Feb 14, 2014 at 1:34 AM, Mathias Bynens math...@qiwi.be wrote:
Allen mentioned that `String#at` might not make it to ES6 because nobody
in TC39 is championing it. I've now asked Rick if he would be the champion
for this, and he agreed. (Thanks again!)
Published to wiki here:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at
On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote:
Allen mentioned that `String#at` might not make it to ES6 because nobody in
TC39 is championing it. I’ve now asked Rick if he would be the champion for
this, and he agreed. (Thanks again!)
Looking over the ‘TC39 progress’ document at
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning). That's good! Is there a way to do without the
export keyword as well (I've heard rumors of anonymous exports but
haven't
1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.
1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.
3 is fine if you think as if there was a block around the whole thing
On further reflection, #3 does feel like trying to rewrite the past. For
better or worse, non-strict mode allows declarations to persist past the
eval(). And while strict mode provides a license-to-kill on behavior like
that, I don't really see strong justification for that kind of surprise
On Fri, Feb 14, 2014 at 10:59 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote:
Allen mentioned that `String#at` might not make it to ES6 because nobody
in TC39 is championing it. I've now asked Rick if he would be the champion
for this,
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here. The
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
As far I know the only way to use the es6 module loader without exports or
imports is to set values on 'this', the global object. I guess it's not
very different from using IIFE (function() {
I'm excited to start working on es7-shim once we get to that point!
(String.prototype.at has a particularly simple shim, thankfully...)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Feb 14, 2014 at 12:23 PM, C. Scott Ananian ecmascr...@cscott.netwrote:
I'm excited to start working on es7-shim once we get to that point!
(String.prototype.at has a particularly simple shim, thankfully...)
Have you seen: https://github.com/mathiasbynens/String.prototype.at ?
Rick
erik: I'd be interested in learning the outcome of the normalization
discussion. As one of the maintainers of es6-shim I'm particularly
interested in ways to access ES6 features with ES5 syntax. If that
looks like:
```js
this['default'] = Promise.join(System.import('foo'),
yes, of course. es6-shim is a large-ish collection of such.
However, it would be much better to use an implementation of
`String#at` which used substr and thus avoided creating and appending
a new string object.
--scott
___
es-discuss mailing list
For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546
`Array#copyWithin` has a (non-normative) signature of `(target, start,
end = this.length)`. However, this is slightly misleading because the
spec actually calls `ToLength` on `this.length` and then uses *that*
for the default value
On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote:
For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546
`Array#copyWithin` has a (non-normative) signature of `(target, start,
end = this.length)`. However, this is slightly misleading because the
spec actually calls `ToLength`
On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote:
On further reflection, #3 does feel like trying to rewrite the past. For
better or worse, non-strict mode allows declarations to persist past the
eval(). And while strict mode provides a license-to-kill on behavior like
that, I don't
On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote:
/ For reference:https://bugs.ecmascript.org/show_bug.cgi?id=2546
//
// `Array#copyWithin` has a (non-normative) signature of `(target, start,
// end = this.length)`. However, this is slightly misleading because the
// spec actually
Le 14 févr. 2014 à 21:46, C. Scott Ananian ecmascr...@cscott.net a écrit :
array-likes with negative length
Array-likes with negative length doesn't make sense, or at least it isn't a
useful concept as far as ECMAScript is concerned – as it doesn't make sense to
consider arraylikes of
On Fri, Feb 14, 2014 at 11:50 AM, André Bargull andre.barg...@udo.edu wrote:
I think Scott is requesting this change:
https://gist.github.com/anba/6c75c34c72d4ffaa8de7
Yes, although my proposed diff (in the linked bug) was the shorter,
12. If end is undefined, let relativeEnd be
On Fri, Feb 14, 2014 at 6:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
To be clear, we fixed this. And we will be going ahead and shipping
promises in Firefox 29. Too many dependencies at this point to hold of
longer.
Since both Chrome and FIrefox have plans to support Promises, feel
free
On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote:
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
Rumors is a bit much. :) The notes do show the discussion but the resolution
for some reason didn't get recorded. IIRC
On Fri, Feb 14, 2014 at 12:59 PM, David Herman dher...@mozilla.com wrote:
https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update
Yeah, I read that, and I thought the absence of a 'Resolution' was a
bit suspicious. I thought
I don't think the details in System will be important, as you suggest there
is not much to say. The critical issue is whether we will have access to an
ES6 specified Loader class. The Loader class and System.fetch is enough I
think to do any custom loader thing one wants. If we only have System
Le 14 févr. 2014 à 23:40, C. Scott Ananian ecmascr...@cscott.net a écrit :
Claude Pache wrote:
Array-likes with negative length doesn't make sense.
`Array.prototype.copyWithin.call({ length: -1 }, ... );`
Call it whatever you like, although I'm always interested in learning
new
Allen Wirfs-Brock wrote:
the various forms of eval are already micro-mode, so I'm not sure if those
points are very relevant.
No, the various forms of eval do not have non-local effects of the kind
your #2 did!
/be
___
es-discuss mailing list
Allen Wirfs-Brock wrote:
On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote:
On further reflection, #3 does feel like trying to rewrite the past. For
better or worse, non-strict mode allows declarations to persist past the eval().
And while strict mode provides a license-to-kill on
47 matches
Mail list logo
