* Axel Rauschmayer wrote:
I’m in the process of coming up with a good title for a book on
ECMAScript 6. That begs the question: What is the best way to refer to
ECMAScript 6?
1. The obvious choices: ECMAScript 6 or ES6.
2. Suggested by Allen [1]: JavaScript 2015.
The advantage of #2 is that
* Boris Zbarsky wrote:
You say every WindowProxy, but in practice in an ES implementation you
have some object, it has some internal methods. This is the last time
I'm bothering to go through this with you, since clearly we're getting
nowhere, as I said in
* Erik Arvidsson wrote:
At the last f2f2 we talked about renaming WeakMap to SideTable. We
postponed the discussion, saying that we would get back to it later. We
never did.
I would like us to keep the name WeakMap as it is. We didn't really take
WeakSet into account. If we rename WeakMap we
* Allen Wirfs-Brock wrote:
On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no other
discussion of JSON and a clear indication that future editions
* Allen Wirfs-Brock wrote:
This whole issue of the use of Syntax Diagrams rather than BNF is a
stylist debate that is hard to take seriously. If TC39 informed you that
we are converting the notation used in ECMA-404 to a BNF formalism would
that end the objections to normatively referencing
* Martin J. Dürst wrote:
The textual descriptions are in some cases quite precise, but in some
other cases, leave quite a bit of ambiguity. And stuff like It may have
an exponent of ten, prefixed by e (U+0065) or E (U+0045) and optionally
+ (U+002B) or – (U+002D). (in particlar the first clause
* Allen Wirfs-Brock wrote:
start JSON text-
{
allenwb: there is an objectively observable order to the members of a JSON
object,
JSON WG participant 1: It would be insane to depend upon that ordering,
allenwb: not if there is agreement between a producer and consumer on
* Allen Wirfs-Brock wrote:
On Dec 7, 2013, at 3:55 AM, Nico Williams wrote:
However, if a schema is also to be allowed to treat them as distinct
then the *meta-schema* must treat them as distinct. I.e., no matter
what generic programming language bindings of JSON one users, the above
two JSON
* Allen Wirfs-Brock wrote:
On Dec 7, 2013, at 4:55 PM, John Cowan wrote:
Allen Wirfs-Brock scripsit:
Similarly, the JSON texts:
{1: 1, 2, 2}
and
{2: 2, 1: 1}
or the JSON texts:
{a: 1, a: 2}
and
{a: 2, a: 1}
have an ordering of the object members that must be preserved by
* Nico Williams wrote:
We must not require encoding detection functionality in parsers. We
must not forbid it either. We might need to say that encodings other
than UTF-8/16/32 may not be reliably detected, therefore they are highly
discouraged, even forbidden except where protocols specifically
* Nico Williams wrote:
On Tue, Nov 26, 2013 at 09:15:38PM +0100, Bjoern Hoehrmann wrote:
* Nico Williams wrote:
We must not require encoding detection functionality in parsers. We
must not forbid it either. We might need to say that encodings other
than UTF-8/16/32 may not be reliably
* Matt Miller (mamille2) wrote:
There does not appear to be any consensus on explicitly allowing or
disallowing of a Byte Order Mark (BOM). Neither RFC4627 nor the current
draft mention BOM anywhere, and the modus operandi of the JSON Working
Group has been to leave text unchanged unless there
* Matt Miller (mamille2) wrote:
There does seem to be rough consensus that using an encoding other than
UTF-8 can have interoperability issues. The also seems to be rough
consensus that the current text and table in section 8.1 for detecting
the encoding will be inaccurate (and potentially
* Allen Wirfs-Brock wrote:
On Nov 21, 2013, at 5:28 AM, Henri Sivonen wrote:
On Thu, Nov 21, 2013 at 7:53 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Just to be clear about this. My tests directly tested JavaScript built-in
JSON parsers WRT to BOM support in three major browsers. The
* John Cowan wrote:
Bjoern Hoehrmann scripsit:
Is there any chance, by the way, to change `JSON.stringify` so it does
not output strings that cannot be encoded using UTF-8? Specifically,
JSON.stringify(JSON.parse(\\uD800\))
would need to escape the surrogate instead of emitting
* Tatu Saloranta wrote:
Dominant Java implementations support UTF-16 with BOM; either directly or
through Java's Reader implementations that handle BOMs.
String concatenation case seems irrelevant, since BOMs are not included in
in-memory representation anyway, as opposed to byte stream
* Martin J. Dürst wrote:
As for what to say about whether to accept BOMs or not, I'd really want
to know what the various existing parsers do. If they accept BOMs, then
we can say they should accept BOMs. If they don't accept BOMs, then we
should say that they don't.
Unicode signatures are not
* Henry S. Thompson wrote:
I'm curious to know what level you're invoking the parser at. As
implied by my previous post about the Python 'requests' package, it
handles application/json resources by stripping any initial BOM it
finds -- you can try this with
import requests
* mn...@google.com wrote:
The first four bytes are:
00 00 00 22 UTF-32BE
00 22 E5 65 UTF-16BE
22 00 00 00 UTF-32LE
22 00 65 E5 UTF-16LE
22 E6 97 A5 UTF-8
The UTF-16 bytes don't match the patterns in RFC, so UTF-16 streams would
* Allen Wirfs-Brock wrote:
On Oct 28, 2013, at 5:52 PM, Domenic Denicola wrote:
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
So what's so onerous about returning a fresh array from the getter each
time it was called.
The fact that `api.property !== api.property`.
You mean
* Norbert Lindenberg wrote:
On Oct 25, 2013, at 18:35 , Jason Orendorff jason.orendo...@gmail.com wrote:
UTF-16 is designed so that you can search based on code units
alone, without computing boundaries. RegExp searches fall in this
category.
Not if the RegExp is case insensitive, or uses a
* Claude Pache wrote:
You might know that the following ES expressions are broken:
text.charAt(0) // get the first character of the text
text.length 100 ? text.substring(0,100) + '...' : text // cut the
text after 100 characters
The reason is *not* because ES works with UTF-16
* Mathias Bynens wrote:
Out of curiosity, is there any programming language that operates on
grapheme clusters (rather than code points) by default? FWIW, code point
iteration is what I’d expect in any language.
It is the specified default for Perl 6 that can be modified through
lexically
* Allen Wirfs-Brock wrote:
The utility of a hypothetical 'at' method is presumably exactly that of
'codePointAt'.
str.at(p)
would just be a convenience for expressing
String.fromCodePoint(str.codePointAt(p))
So the real question is probably, how common is that use case.
Certainly not
* Mathias Bynens wrote:
On 19 Oct 2013, at 12:15, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Certainly not common enough to warrant a two-character method on the
native string type. Odds are people will use it incorrectly in an
attempt to make their code look concise […]
Are you saying
* Allen Wirfs-Brock wrote:
As far as far as I know, nobody has suggested that TC39 should issues a
standard relating to this encoding level or concerning the JSON MIME
type. This seems like an appropriate subject area for the IETF.
Per
* Anne van Kesteren wrote:
I think I'm convinced that String.fromCodePoint()'s design is correct,
especially since the rendering subsystem deals with code points too.
String.prototype.codePointAt() however still feels wrong since you
always need to iterate from the start to get the correct code
* Anne van Kesteren wrote:
ES6 introduces String.prototype.codePointAt() and
String.codePointFrom() as well as an iterator (not defined). It struck
me this is the only place in the platform where we'd expose code point
as a concept to developers.
Nowadays strings are either 16-bit code units
* Andy Earnshaw wrote:
typeof null == null is a different case though. typeof is a requirement
for checking the existence of pre-declared variables, so you could expect
something like, if (typeof someVar === object someVar === null), to
appear at least in a few places on the web. Tab's saying
* Brendan Eich wrote:
We could also introduce binary =, AKA cmp, return -1, 0, or 1.
Imagine the sort fun:
a.sort((a, b) = a = b)
:-P. The win over using
a.sort((a, b) = a - b)
is that = would work as expected for string-typed a and b as well.
In Perl = compares as if the operands had
* Jonas Sicking wrote:
Then there's of course the issue of what we should do with APIs that
combine several Futures into a single one. Like Future.every() etc.
Similarly, there's also the issue of what to do with chaining.
I'm tempted to say that if you create combined or dependent Futures,
you
* Jonas Sicking wrote:
I do not think that we should add cancellation on the base Future
interface. I.e. we shouldn't make *all* Futures cancellable.
Cancelability should only be possible when the implementation of the
Future would actually stop doing work if the Future is cancelled. I.e.
* Sam Tobin-Hochstadt wrote:
What exactly would be the semantic difference between this and just using
'yield'?
If you consider it from the perspective of someone reading the code, you
might find, as an example, `try { ... yield ... }` rather weird (how can
yielding control fail?) while `try {
* Andrea Giammarchi wrote:
not sure I understand those examples, but the moment a developer starts
yelding everything, is the moment all non-blovking asynchronous advantages
are gone 'cause you are waiting instead of keep doing the rest, isn't it?
A simple example would be an application running
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler like `Q.async`
or `taskjs.spawn`. We could add that sugar if we wanted,
* Sam Tobin-Hochstadt wrote:
On Sun, Apr 21, 2013 at 9:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function
* Tab Atkins Jr. wrote:
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
I'm not seeing what in this proposal can't be implemented in
JavaScript as it is today. Is there an implementation of this
somewhere? Are there any programs that use these streams?
This is a
* Kenneth Russell wrote:
No. The typed array views (everything except DataView) have used the
host machine's endianness from day one by design -- although the typed
array spec does not state this explicitly. If desired, text can be
added to the specification to this effect.
That seems to be
* Jeff Walden wrote:
On 03/03/2013 06:49 PM, Rick Waldron wrote:
Is this +1 to findIndex?
Not that I much care between the two, just making sure another
reasonable name is considered, but I'm not sure why it wouldn't be named
find rather than findIndex. The index seems like the only bit
* David Bruant wrote:
One (minor) annoyance with forEach/map, etc. is that the enumeration
can't be stopped until all elements have been traversed which doesn't
suit every use case. One hack to stop the enumeration is to throw an
error but that requires to wrap the .forEach call in a try/catch
* David Bruant wrote:
I've found myself multiple times in a situation where I needed the index
of the first element responding to some conditions. I solved it the
following way:
var index;
array.some(function(e, i){
if(someCondition(e)){
index = i;
41 matches
Mail list logo
