A rough guide for migrating functions from ES5 to ES6 would be:
1. Function declarations -- function declarations
2. Function expressions -- arrow functions
3. IIFEs -- blocks
4. Functions in object literals -- concise method syntax
5. Constructors -- classes
6. New: generator functions
These
But, according to spec, \8 and \9 SHOULD cause a syntax error.
Because in string literals,
EscapeSequence - CharacterEscapeSequence
and
CharacterEscapeSequence - SingleEscapeCharacterCharacterEscapeSequence -
NonEscapeCharacter
The NonEscapeCharacter is defined as SourceCharacter minus
It seems to me that there are two different use cases for privacy:
Use case 1: Hide some properties from the outside (when listing properties or
getting expansion help from an IDE). Many people use a naming convention here
(e.g. a prefixed underscore). This hiding does not have to be completely
The function for use case #1 seems to be Object.getOwnPropertyKeys()
[15.2.3.15]:
js Object.keys(Array)
[]
js Object.getOwnPropertyNames(Array)
[length,name,prototype,isArray,of,from,caller,arguments]
js [for (x of Object.getOwnPropertyKeys(Array)) x]
Le 25 mars 2013 à 08:28, Axel Rauschmayer a...@rauschma.de a écrit :
2. Function expressions -- arrow functions
No, it depends. Roughly, I would replace function expressions by arrow
functions when I want to use the 'this' binding of the enclosing scope (or
don't use the 'this' binding), and
I tried posting this before, but it seems to have gotten lost on the
internet.
One thing which is impossible to make in JavaScript today is a weakly
referenced event listener system. In such a system an event listener is not
strongly referenced by the event system, so events are only dispatched
Most use cases I've personally seen for weak events would be satisfied by a
WeakMap of weak event target - event handler. Having the event handler
itself be weak instead of the event target seems strange to me; it
introduces a bunch of nondeterministic behavior that isn't desirable -
sometimes
On Mon, Mar 25, 2013 at 3:28 AM, Axel Rauschmayer a...@rauschma.de wrote:
A rough guide for migrating functions from ES5 to ES6 would be:
1. Function declarations -- function declarations
2. Function expressions -- arrow functions
Claude nailed this one
3. IIFEs -- blocks
or Modules
I expect the module champions to be busy, so I am not expecting a
response. This is just some feedback to consider or discard at their
discretion. I'll wait for the next public update on modules to see
where things end up. In general, sounds promising.
I'm going off the meeting notes from here
On Mar 25, 2013, at 1:57 AM, Claude Pache wrote:
Le 25 mars 2013 à 08:28, Axel Rauschmayer a...@rauschma.de a écrit :
2. Function expressions -- arrow functions
No, it depends. Roughly, I would replace function expressions by arrow
functions when I want to use the 'this' binding of
Possibly worth mentioning: If you use `super` then Object.defineProperty() does
not work, only Object.assign() and Object.mixin() update [[HomeObject]]. AFAIK,
we don’t have Object.defineMethod() yet (maybe ever).
On Mar 25, 2013, at 19:09 , Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On
On Fri, Mar 22, 2013 at 7:47 PM, Brendan Eich bren...@mozilla.com wrote:
Kenneth Russell wrote:
I hope that the ES6 integration of typed arrays will not require
normalization of NaNs on write, even if other specification changes
need to be made to avoid requiring it.
What other
On Fri, Mar 22, 2013 at 10:34 PM, David Herman dher...@mozilla.com wrote:
On Mar 22, 2013, at 7:47 PM, Brendan Eich bren...@mozilla.com wrote:
Kenneth Russell wrote:
I hope that the ES6 integration of typed arrays will not require
normalization of NaNs on write, even if other specification
On Mon, Mar 25, 2013 at 1:31 PM, James Burke jrbu...@gmail.com wrote:
I expect the module champions to be busy, so I am not expecting a
response. This is just some feedback to consider or discard at their
discretion. I'll wait for the next public update on modules to see
where things end up.
Kenneth Russell wrote:
For interop, JS requires cross-browser (VM) NaN canonicalization to avoid
observably different results on different browsers.
As long as NaN values loaded from Float32Array and Float64Array obey
ES6's semantics, such as returning true from isNaN(), then it should
not
On Mon, Mar 25, 2013 at 2:40 PM, Brendan Eich bren...@mozilla.com wrote:
Kenneth Russell wrote:
For interop, JS requires cross-browser (VM) NaN canonicalization to
avoid
observably different results on different browsers.
As long as NaN values loaded from Float32Array and Float64Array
On Mar 25, 2013, at 2:40 PM, Brendan Eich wrote:
Kenneth Russell wrote:
For interop, JS requires cross-browser (VM) NaN canonicalization to avoid
observably different results on different browsers.
As long as NaN values loaded from Float32Array and Float64Array obey
ES6's semantics,
Allen Wirfs-Brock wrote:
BTW, isn't cannonicalization of endian-ness for both integers and floats a
bigger interop issue than NaN cannonicalization? I know this was discussed in
the past, but it doesn't seem to be covered in the latest Khronos spec. Was
there ever a resolution as to whether
On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
BTW, isn't cannonicalization of endian-ness for both integers and floats a
bigger interop issue than NaN cannonicalization? I know this was discussed
in the past, but it doesn't seem to be covered in the latest
Allen Wirfs-Brock wrote:
On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
BTW, isn't cannonicalization of endian-ness for both integers and floats a
bigger interop issue than NaN cannonicalization? I know this was discussed in
the past, but it doesn't seem to be
On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
BTW, isn't cannonicalization of endian-ness for both integers and floats
a bigger interop issue than NaN
Right, thanks for the reminder. It all comes back now, including the how to
write correct ending-independent typed array code bit.
/be
On Mar 25, 2013, at 4:33 PM, Kenneth Russell k...@google.com wrote:
On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich bren...@mozilla.com wrote:
Allen
On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
Right, thanks for the reminder. It all comes back now, including the how to
write correct ending-independent typed array code bit.
Ok, so looping back to my earlier observation. It sounds like endian-ness can
be observed by writing into an
* 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
On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
Right, thanks for the reminder. It all comes back now, including the how to
write correct ending-independent typed array code bit.
Ok, so looping back to my
WeakMap would not work in this specific case since a WeakMap cannot be
iteratered.
WeakRefs are needed to do data binding and pub sub systems like these.
WeakRefs are very likely to be part of ES7. We haven't really talked much
about them formally but informally TC39 members seems to agree.
On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote:
One thing which is impossible to make in JavaScript today is a weakly
referenced event listener system. In such a system an event listener is not
strongly referenced by the event system, so events are only dispatched
Very true, I'm wondering if based on usage today it could make sense to have
this as default behavior on current API?
Benoit
On Mar 25, 2013, at 19:51, Peter Michaux petermich...@gmail.com wrote:
On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote:
One thing which
Hi Sam,
I really was not expecting a reply, as it was a lot of feedback. Just
wanted to get some things in the to be considered at some point/use
case queue. Some clarifications, but I do not think it is worth
continuing discussion here given the breadth of the feedback and the
stage of the spec
29 matches
Mail list logo
