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 > wrote: > > I've learned it the hard way ... when in doubt, see what Firefox does ... > usual

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

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/dgr

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

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 wrote: > >> No, what is required is >> >> (() => {...whatever...})() >> >> Arrow function expressions are an AssignmentExpression. > > > Right, I m

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 wrote: > Thanks for the reply. >> >> I'd actually expect `undefined` because function declarations does not >> return anything. Converting it to a function expressi

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-discu

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 S

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 January 8, 2014 1:21 PM sorry, actually the right example was

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

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 _

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 d

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

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 wrote: > Dwayne wrote: > >> UDP Datagrams. >> > > Use a Uint8Array and string decoding/encoding API. Browsers have to copy > anyway, y

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

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:/

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. S

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 ar

Re: Need a champion? StringView strawman

UDP Datagrams. On Fri, Jan 10, 2014 at 3:28 PM, Brendan Eich 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. >

Re: Need a champion? StringView strawman

On Fri, Jan 10, 2014 at 3:14 PM, Boris Zbarsky 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

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

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 o

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-88

Re: Enumerability

Le 9 janv. 2014 à 12:21, Axel Rauschmayer 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-enumer

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 opt

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 optimiz

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 c

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 > 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/W

Re: Need a champion? StringView strawman

On Fri, Jan 10, 2014 at 10:26 AM, Anne van Kesteren wrote: > > On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock > 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-

Re: Need a champion? StringView strawman

On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock 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

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"