Need a champion? StringView strawman
https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that StringView [1] over ArrayBuffers be added to ES. The current StringView proposal is a WebIDL based design and not particularly integrated into the ES6 Typed Array support, the ES6 Unicode support, or the post ES6 Binary Data work. It isn't clear to me exactly how much, if any, momentum this proposal has in any standards process outside of TC39. However, if something like it is going to emerge TC39 should be involved early to ensure that it is well integrated into ES. It sounds to me like we need a TC39 champion (or perhaps an anti-champioin) to shepherd this work in the context of the new TC39 development process. Any volunteers? I can help but have limited time available for this right now. Allen [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that StringView [1] over ArrayBuffers be added to ES. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView Where is this from? Google and Mozilla have implemented the API from http://encoding.spec.whatwg.org/ as a means to get strings out of bytes (and bytes out of strings). It's not clear we need anything else. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On Fri, Jan 10, 2014 at 10:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that StringView [1] over ArrayBuffers be added to ES. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView Where is this from? Google and Mozilla have implemented the API from http://encoding.spec.whatwg.org/ as a means to get strings out of bytes (and bytes out of strings). It's not clear we need anything else. There was some discussion about implementing StringView on the blink-dev mailing list in August 2013. My opinion was and is that the Encoding spec satisfies these use cases. Adding a StringView to Typed Arrays would bring along all of the complexities of character set encoding and decoding to the Typed Array definitions. Typed Arrays were designed to be small, simple, and comprehensible enough that they would be easily implementable and optimizable. I believe that adding a StringView would contradict these goals. -Ken ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On Jan 10, 2014, at 10:26 AM, Anne van Kesteren wrote: On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that StringView [1] over ArrayBuffers be added to ES. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView Where is this from? Don't know, I'm just creating visibility of the ES bug/feature request. Google and Mozilla have implemented the API from http://encoding.spec.whatwg.org/ as a means to get strings out of bytes (and bytes out of strings). It's not clear we need anything else. Same base point applies to that proposal. If anybody wants this capability to be considered as a standard ES capability, it needs to have a champion within TC39. I note that (as would be expected) the whatwg encoding spec. is expressed in WebIDL terms (DOMStrings, etc.) and it isn't yet clear to me how well it integrates with ES, ES standard library conventions, or non-browser hosts. Perhaps it's fine to leave this as a web platform API , but support for character set encoding/decoding is a general purpose capabilities and it might be reasonable to have a solution that isn't tied to a specific environment. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enumerability
Axel Rauschmayer wrote: * At the moment, only Object.keys and the for-in loop are affected by it. * In ECMAScript 6, Object.assign will also ignore non-enumerable properties. Pave that cowpath! * Built-in prototype methods are non-enumerable, as is property `length` of arrays. Good, more consistency with existing objects. * In ECMAScript 6, prototype methods created by classes are enumerable, the prototype method `constructor` is non-enumerable (as it is by default in all functions). This may be a mistake. Prototype methods defined in JS are enumerable up to ES5 unless you use Object.defineProperty. Prototype methods on builtins are not enumerable. Something has to give. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
Kenneth Russell wrote: Adding a StringView to Typed Arrays would bring along all of the complexities of character set encoding and decoding to the Typed Array definitions. Typed Arrays were designed to be small, simple, and comprehensible enough that they would be easily implementable and optimizable. I believe that adding a StringView would contradict these goals. + a lot. What can we do to make sure this thing stays dead, if it is dead? Anne may know some weird W3C protocol trick. ;-) /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
I disagree. I think this should progress. It doesn't have to add any additional functionality to Typed Arrays. As it stands I would consider it a replacement for the purposes of TextEncoder and TextDecoder APIs. Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid encoding option and defaults to UTF-8, if left unspecified. On Fri, Jan 10, 2014 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote: Kenneth Russell wrote: Adding a StringView to Typed Arrays would bring along all of the complexities of character set encoding and decoding to the Typed Array definitions. Typed Arrays were designed to be small, simple, and comprehensible enough that they would be easily implementable and optimizable. I believe that adding a StringView would contradict these goals. + a lot. What can we do to make sure this thing stays dead, if it is dead? Anne may know some weird W3C protocol trick. ;-) /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enumerability
Le 9 janv. 2014 à 12:21, Axel Rauschmayer a...@rauschma.de a écrit :
I’m still really unhappy about enumerability in ECMAScript. I find it
frustratingly inconsistent:
* At the moment, only Object.keys and the for-in loop are affected by it.
* In ECMAScript 6, Object.assign will also ignore non-enumerable properties.
You forgot an important fact: While legacy `for/in` loop takes inherited
properties into account, all newer constructs are only affected by *own*
enumerable properties. You also forgot to mention `JSON.stringify`, which also
takes only own enumerable properties into account. I guess that, in the long
run, enumerability will be really significant for own properties only.
* Built-in prototype methods are non-enumerable, as is property `length` of
arrays.
* In ECMAScript 6, prototype methods created by classes are enumerable, the
prototype method `constructor` is non-enumerable (as it is by default in all
functions).
I’ve seen various explanations for what enumerability is:
1. Something that won’t matter in the long run. But then why are we
introducing new constructs that take it into consideration?
2. Something that one has to do properly so that old code doesn’t break.
Here, it’d be helpful to be concrete: where can this happen? The obvious case
is for-in for instances of built-in constructors.
3. Signaling an intent of sharing. But what does that mean in practice? Why
are built-in methods different from user-defined methods in this regard?
4. A way of marking a method as private. Again: why the divergence between
built-in methods and user-defined methods?
I think it would really help the design of ECMAScript going forward if we had
a definitive and complete explanation of what enumerability is now and what
it should be in the future. I’m trying to make sense of it and to explain it
to others and continue to fail.
I can't provide a definite abstract explanation, but here is a practical
situation where I've found non-enumerability a useful feature, although it does
not exactly fit any of the four explanations you cited. Consider some tree
structure:
obj = { foo: 1, bar: 2, children : [ { foo: 5, bar: 4 }, { foo: 2, bar: 4,
children: [...] } ] }
When walking through such a tree, I typically want to have access (for example)
to the parent of a node (just like the `parentNode` method of `Node` objects in
the DOM). For that end, I define a *non-enumerable* `_parent` property on each
node, which refers back to its parent node. Now, although I have polluted each
node with a supplementary property,
* I can happily invoke `Object.keys` on a node, and it will give me back the
correct answer;
* I can happily serialise my tree using `JSON.stringify`, and it won't complain
that it can't handle cyclic structures. After deserialising it with
`JSON.parse`, I just have to recursively reconstruct the `_parent`
back-references;
* etc.
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On 1/10/14 3:47 PM, Dwayne wrote: Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid encoding option I'm curious. What would you expect such an option to do? Byte-inflate like ISO-8859-1? Byte-inflate but throw on bytes with values 127? Act as a synonym for ISO-8859-9? Something else? and defaults to UTF-8, if left unspecified. Right, because it's meant for text, and for text UTF-8 is a pretty reasonable default nowadays. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enumerability
I hope this won't be considered spam and slightly OT but you can already
happily serialize with an enumerable parent via reviver and serializer
functions or simply using CircularJSON [1] which seems to be ideal for your
very specific case so that you don't have to do anything once deserialized
in order to have exactly same structure back.
I mostly agree with Axel, specially on the class side. I have a redefine
utility that indeed defines by default all class properties and methods not
enumerable since *own* property is usually what matters, the class should
not affect for/in at all as we expect with any other native class.
+1 for non enumerable by default ... class are a new thing in any case,
these could desugar to Object.defineProperties in the class prototype
instead of simply assigning them.
I know TypeScript chaps will hate me for such idea
[1] https://github.com/WebReflection/circular-json#circularjson
Regards
On Fri, Jan 10, 2014 at 12:58 PM, Claude Pache claude.pa...@gmail.comwrote:
Le 9 janv. 2014 à 12:21, Axel Rauschmayer a...@rauschma.de a écrit :
I’m still really unhappy about enumerability in ECMAScript. I find it
frustratingly inconsistent:
* At the moment, only Object.keys and the for-in loop are affected by it.
* In ECMAScript 6, Object.assign will also ignore non-enumerable
properties.
You forgot an important fact: While legacy `for/in` loop takes inherited
properties into account, all newer constructs are only affected by *own*
enumerable properties. You also forgot to mention `JSON.stringify`, which
also takes only own enumerable properties into account. I guess that, in
the long run, enumerability will be really significant for own properties
only.
* Built-in prototype methods are non-enumerable, as is property `length`
of arrays.
* In ECMAScript 6, prototype methods created by classes are enumerable,
the prototype method `constructor` is non-enumerable (as it is by default
in all functions).
I’ve seen various explanations for what enumerability is:
1. Something that won’t matter in the long run. But then why are we
introducing new constructs that take it into consideration?
2. Something that one has to do properly so that old code doesn’t break.
Here, it’d be helpful to be concrete: where can this happen? The obvious
case is for-in for instances of built-in constructors.
3. Signaling an intent of sharing. But what does that mean in practice?
Why are built-in methods different from user-defined methods in this regard?
4. A way of marking a method as private. Again: why the divergence
between built-in methods and user-defined methods?
I think it would really help the design of ECMAScript going forward if
we had a definitive and complete explanation of what enumerability is now
and what it should be in the future. I’m trying to make sense of it and to
explain it to others and continue to fail.
I can't provide a definite abstract explanation, but here is a practical
situation where I've found non-enumerability a useful feature, although it
does not exactly fit any of the four explanations you cited. Consider some
tree structure:
obj = { foo: 1, bar: 2, children : [ { foo: 5, bar: 4 }, { foo: 2,
bar: 4, children: [...] } ] }
When walking through such a tree, I typically want to have access (for
example) to the parent of a node (just like the `parentNode` method of
`Node` objects in the DOM). For that end, I define a *non-enumerable*
`_parent` property on each node, which refers back to its parent node. Now,
although I have polluted each node with a supplementary property,
* I can happily invoke `Object.keys` on a node, and it will give me back
the correct answer;
* I can happily serialise my tree using `JSON.stringify`, and it won't
complain that it can't handle cyclic structures. After deserialising it
with `JSON.parse`, I just have to recursively reconstruct the `_parent`
back-references;
* etc.
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
Dwayne wrote: Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid encoding option and defaults to UTF-8, if left unspecified. That's a feature. The '90s are over, let's not go back. Why do you want ASCII, and what do you do with it? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On Fri, Jan 10, 2014 at 3:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: I'm curious. What would you expect such an option to do? Byte-inflate like ISO-8859-1? Byte-inflate but throw on bytes with values 127? Act as a synonym for ISO-8859-9? Something else? Exactly how StringView handles the option now. If I generate a random string using byte values then each char in that string should correspond to a single byte when specifying the ISO-8859-1. It doesn't really make since to use UTF-8 for bytes when that data should be manipulated as bytes in the first place. In the case of data being represented as a string but need to be handled as bytes. https://bugzilla.mozilla.org/show_bug.cgi?id=957424 UTF-8 being the default is not the problem of course. Throwing an exception for ASCII is. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
UDP Datagrams. On Fri, Jan 10, 2014 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote: Dwayne wrote: Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid encoding option and defaults to UTF-8, if left unspecified. That's a feature. The '90s are over, let's not go back. Why do you want ASCII, and what do you do with it? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On 1/10/14 4:29 PM, Dwayne wrote: Exactly how StringView handles the option now. If I generate a random string using byte values then each char in that string should correspond to a single byte when specifying the ISO-8859-1. OK, so specify ISO-8859-1, if that's what you're really doing. Or are you saying that you just want ascii to be a synonym for iso-8859-1 here? But it'd be a lie, because ASCII actually means something, and it means something different from ISO-8859-1. But really, if you just have bytes, not text, why are you generating a string from those byte values at all? This is where a typed array would make more sense... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
I mean char code points in the range (0-255) a byte. Use the desired terminology or name. Primarily because of this bug - Expose raw data on UDP socket messages: https://bugzilla.mozilla.org/show_bug.cgi?id=952927 I generate a random string using code points that I eventually convert to bytes. Specifically in the case of a two or 20 char/byte ID. Where I need to be able to use the entire 16 bit or 160 space and then send as bytes and trust that ID will be same for both parties consistently. -- To elaborate, I need to bencode this information before converting to bytes. I understand all of this could be worked around by just using String.charCodeAt or the synonymous String.codePointAt but why then have such a powerful API and disallow the fore-mentioned feature? And why exactly have to separate APIs? On Fri, Jan 10, 2014 at 3:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/10/14 4:29 PM, Dwayne wrote: Exactly how StringView handles the option now. If I generate a random string using byte values then each char in that string should correspond to a single byte when specifying the ISO-8859-1. OK, so specify ISO-8859-1, if that's what you're really doing. Or are you saying that you just want ascii to be a synonym for iso-8859-1 here? But it'd be a lie, because ASCII actually means something, and it means something different from ISO-8859-1. But really, if you just have bytes, not text, why are you generating a string from those byte values at all? This is where a typed array would make more sense... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
Dwayne wrote: UDP Datagrams. Use a Uint8Array and string decoding/encoding API. Browsers have to copy anyway, you're not optimizing by using the (soon to be dead, I hope) StringView. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enumerability
On Jan 10, 2014, at 11:49 AM, Brendan Eich wrote:
Axel Rauschmayer wrote:
* Built-in prototype methods are non-enumerable, as is property `length` of
arrays.
Good, more consistency with existing objects.
* In ECMAScript 6, prototype methods created by classes are enumerable, the
prototype method `constructor` is non-enumerable (as it is by default in all
functions).
This may be a mistake. Prototype methods defined in JS are enumerable up to
ES5 unless you use Object.defineProperty. Prototype methods on builtins are
not enumerable. Something has to give.
The ES6 class specification originally made prototype methods (we didn't have
static methods at the time) non-enumerable.
That was changed at the Sept 19, 2012 TC39 meeting
https://mail.mozilla.org/pipermail/es-discuss/2012-September/025231.html
# Concise Method Definition, Revisited
RW: Defaulting concise methods to non-enumerable is a mistake
DH: Not sure about the decision to go non-enumerable. Users expect that
things they create to be enumerable and things that the platform provides
to be non-enumerable.
LH: enumerability is not a real concept with any sort of meaning.
EA: (reveals the broken-ness of the DOM)
No longer arguable.
**Conclusion/Resolution**
Concise method definitions create [[Enumerable]]: true
I went along with the majority, although I don't really like it very much.
It's basically a question of whether class definitions follow the pattern of
pre-ES6 built-in or the pattern of pre-ES6 manually constructed
constructor/prototype pairs.
Early on we decided to follow the built-in pattern, but at that meeting we
changed it WRT enumerability of methods.
It comes down to this
class C extends Array {
foo() {}
}
let c = {foo() {}}
let assignedClass = Object.assign({ }, C.prototype);
let assignedObjLit = Object.assign({ }, c);
original class design:
typeof assignedClass.foo //Undefined
typeof assignedObjLit.foo //Undefined
current ES6 spec:
typeof assignedClass.foo //function
typeof assignedObjLit.foo //function
another plausible design:
typeof assignedClass.foo //Undefined
typeof assignedObjLit.foo //function
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
No joke. But as far as optimization goes I'm limited. You wrote the book so thanks for at least hearing me out. ;) On Fri, Jan 10, 2014 at 4:07 PM, Brendan Eich bren...@mozilla.com wrote: Dwayne wrote: UDP Datagrams. Use a Uint8Array and string decoding/encoding API. Browsers have to copy anyway, you're not optimizing by using the (soon to be dead, I hope) StringView. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enumerability
The ES6 class specification originally made prototype methods (we didn't have static methods at the time) non-enumerable. That was changed at the Sept 19, 2012 TC39 meeting https://mail.mozilla.org/pipermail/es-discuss/2012-September/025231.html It may make sense if enumerability was repurposed as a runtime flag for privacy (in the sense of “you don’t need to know about this property/method”). That would nicely complement TypeScript’s static-only (= non-runtime) `private` keyword. It’s one of the two – largely orthogonal – use cases I see for privacy: 1. Completely protecting data from “external” access. In ES6, one can use WeakMaps and closures for this. 2. Encapsulation: Hide internal properties from sight, document internal-ness. If it’s advisory only then you can still write “friend” functions etc, without too much of a fuss. ### I’m looking for a simple explanation of what enumerability will be, going forward. If there isn’t one then I’d argue that no new feature should be influenced by it. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enumerability
On Jan 10, 2014, at 2:40 PM, Axel Rauschmayer wrote: ### I’m looking for a simple explanation of what enumerability will be, going forward. If there isn’t one then I’d argue that no new feature should be influenced by it. That was one of the argument made in favor of concise methods defaulting as not enumerable: enumerable really only controls whether a property shows up in for-in (and a couple closely related reflection functions) and for-in has been essentially deprecated and replace by for-of. That makes the enumerable attribute an obsolete feature and we should be trying to give it meaning for new features. Hence, just always default it to true. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
Dwayne wrote: Primarily because of this bug - Expose raw data on UDP socket messages: https://bugzilla.mozilla.org/show_bug.cgi?id=952927 Answering for bz: why do you need string-views or string-anythings to wrangle bytes in and out of a Uint8Array? Can you show some code? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
Kevin Smith wrote:
We should adapt Crock's recommended paren style to arrow IIFEs, to
whit (()={...whatever...}()), even though this looses a bit more
brevity.
I believe this is required by the grammar anyway.
No, what is required is
(() = {...whatever...})()
Arrow function expressions are an AssignmentExpression.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: generators inside DOM events
'yield' in an HTML event attribute value should be a free variable
reference, since the attribute value is taken as the source of a
function body, not of a function* body.
/be
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
January 8, 2014 1:21 PM
sorry, actually the right example was with `while (true) yield evt;`
but that's the same of async callback, the event is gone.
Well, everything good then ^_^
Thanks again
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
January 8, 2014 1:19 PM
OK, I have overlooked at this ... so the following code won't have any
side effect, correct?
```javascript
addEventListener('beforeunload', function (e) {
(function*() {
while (true) yield null;
}());
});
```
Thanks
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brandon Benvie mailto:bben...@mozilla.com
January 8, 2014 1:12 PM
Calling a generator function just creates a paused generator.
Generators can't pause callers, just themselves (via yield).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
January 8, 2014 1:05 PM
Sorry, I explained it badly ... let me try again:
what if a DOM event handler uses/creates/invokes inside its function
body a generator?
Will the event pause until this will be satisfied?
`a.addEventListener('click', function(e){
if(methodThatInvokesGenerator()) e.stopPropagation(); });`
Is this a concern?
Thanks
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Domenic Denicola mailto:dome...@domenicdenicola.com
January 8, 2014 12:53 PM
What? That would just cause the event handler function to return a
generator object, which the browser would not use or do anything with.
It would have no effect.
*From:* es-discuss es-discuss-boun...@mozilla.org on behalf of
Andrea Giammarchi andrea.giammar...@gmail.com
*Sent:* Wednesday, January 08, 2014 15:50
*To:* es-discuss@mozilla.org
*Subject:* generators inside DOM events
I am not sure this has been discussed already but I wonder what would
happen if `yield` is used inside an event such 'beforeunload',
'unload', or even 'click' and others DOM related events.
Main concerns:
1. it's a UA trap potentially making impossible to leave a page or
complete a user meant action
2. not even transpilers can solve cases like this (i.e. a still valid
event eventually stopped after some generator logic where if
simulated the event would be expired at the time the function will
be invoked)
Thanks
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
André Bargull wrote: There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is 12.13.4 Runtime Semantics: Evaluation: The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. Has anyone filed bugs against V8 and Chakra? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
No, what is required is
(() = {...whatever...})()
Arrow function expressions are an AssignmentExpression.
Right, I misread Mark's code sample.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
Thanks, this clarifies things. I'll update the answer on SO to reflect the findings. On Thu, Jan 9, 2014 at 3:54 AM, André Bargull andre.barg...@udo.edu wrote: Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't unambiguously figure out which browser is 'correct'. There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is 12.13.4 Runtime Semantics: Evaluation: The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
You read my sample right. The mistake was mine, and the parens should be
places where Brendan shows.
On Fri, Jan 10, 2014 at 5:48 PM, Kevin Smith zenpars...@gmail.com wrote:
No, what is required is
(() = {...whatever...})()
Arrow function expressions are an AssignmentExpression.
Right, I misread Mark's code sample.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
I've learned it the hard way ... when in doubt, see what Firefox does ... usually that's the meant standard behavior. I really wish JavaScript was a Test Driven developing programming language ... the amount of fragmentation for every single little thing apparently never tested against meant specs is often too damn high! Best Regards On Fri, Jan 10, 2014 at 5:50 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: Thanks, this clarifies things. I'll update the answer on SO to reflect the findings. On Thu, Jan 9, 2014 at 3:54 AM, André Bargull andre.barg...@udo.eduwrote: Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't unambiguously figure out which browser is 'correct'. There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is 12.13.4 Runtime Semantics: Evaluation: The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
Compensate the lack of rawData property -- Bug 952927 Buffer is a Uint8Array which has non standard methods on its prototype using a WeakMap technique. -- This module will be used with BitTorrent PWP as well so its definitely necessary. https://github.com/DecipherCode/Firebit/blob/master/lib/dgram.js#L78 And here is a snippet covering the other reason(s): http://pastebin.mozilla.org/3986282 Thanks. On Fri, Jan 10, 2014 at 7:31 PM, Brendan Eich bren...@mozilla.com wrote: Dwayne wrote: Primarily because of this bug - Expose raw data on UDP socket messages: https://bugzilla.mozilla.org/show_bug.cgi?id=952927 Answering for bz: why do you need string-views or string-anythings to wrangle bytes in and out of a Uint8Array? Can you show some code? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
On 1/10/14 10:46 PM, Dwayne wrote: Compensate the lack of rawData property -- Bug 952927 Sure, but that should be fixed by adding such a property in this case, no? The only reason this is using a string is because it's using a somewhat braindead IDL (_way_ more braindead for purposes of JS sanity than WebIDL is) to expose C data structures pretty directly. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
Things to complain about! JS interop is far better than other languages with multiple implementations. Never mind complex APIs such as the DOM. /be On Jan 10, 2014, at 7:05 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I've learned it the hard way ... when in doubt, see what Firefox does ... usually that's the meant standard behavior. I really wish JavaScript was a Test Driven developing programming language ... the amount of fragmentation for every single little thing apparently never tested against meant specs is often too damn high! Best Regards On Fri, Jan 10, 2014 at 5:50 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: Thanks, this clarifies things. I'll update the answer on SO to reflect the findings. On Thu, Jan 9, 2014 at 3:54 AM, André Bargull andre.barg...@udo.edu wrote: Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't unambiguously figure out which browser is 'correct'. There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is 12.13.4 Runtime Semantics: Evaluation: The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
