Re: Advice/Timeline on using Value Objects?

Tab Atkins Jr. wrote: Using value objects would make this explicit, and would allow convenient operator overloading, so you can do: var x = CSS.px(5); var y = CSS.px(10); var z = x + y; With value objects, you could do even better: // something declarative to import suffix px as CSS.px here

Re: Reason why generators do not have references to themselves?

Andrea Giammarchi wrote: arguments.callee.caller would have done that No, Bradley wants the generator-iterator (what ES6 draft calls a Generator), not the generator function (GeneratorFunction). Any .callee would have to be a function, so a GeneratorFunction. But the gist'ed example won't

Re: SameValueZero comparator and compatibility

Andrea Giammarchi wrote: last 3 points are way too much high-level ... "ask feature champions" & "other TC39 participants" ... how? Just "trashing code" in test262-discuss? Updating test262 is a good idea, but it's not the direct way to get these implementation bugs fixed. File bugs on Spider

Re: Standard modules?

David Bruant wrote: Le 20/01/2014 18:39, Brendan Eich a écrit : Allen Wirfs-Brock wrote: It isn't clear that there much need for a global name for GeneratorFunction. If you really eed to access it can always get it via: (function *() {}).constructor Do we even need (fun

Re: Standard modules?

Allen Wirfs-Brock wrote: It isn't clear that there much need for a global name for GeneratorFunction. If you really eed to access it can always get it via: (function *() {}).constructor Does this present a hazard for CSP, which provides policy controls governing Function? I agree we sh

Re: Rename Number.prototype.clz to Math.clz

Nick Krempel wrote: Whether log(0) is -Infinity or NaN should depend in some sense on what side you approach 0 from (I arbitrarily claim to be approaching it from the left in my formula, to give a NaN result there too). I feel Math.log(-0) should be NaN in js for that reason, but it is define

Re: Rename Number.prototype.clz to Math.clz

Adam Ahmed wrote: Just noting that this actually works: Math.ceil(Math.log(0 + 1) / Math.LN2) === 0 However: Math.ceil(Math.log(-1 + 1) / Math.LN2) === -Infinity That's pretty sweet, but then try -2 or -3 or below and you get NaN. Not sure how that affects a Negative NaN-cy option :) Heh.

Re: Capitalization: symbol vs. Symbol

Symbols are not value objects, they are primitives like strings, and the 'Symbol' function is analogous to 'String'. See http://esdiscuss.org/notes/2013-09-18 Consensus/Resolution * Symbols are a new primitive type with regular wrapper objects * typeof symbol === "symbol" * implicit

Re: Rename Number.prototype.clz to Math.clz

Jason Orendorff wrote: > What is Math.bitlen(-1) then? Isn’t this just the same problem as before, except it happens for negative numbers instead of positive? No opinion. Not sure it matters. We could return -1 for any negative number, 0 for 0, and > 0 for positive integral values. /be _

Re: Rename Number.prototype.clz to Math.clz

Kevin Reid wrote: On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich <mailto:bren...@mozilla.com>> wrote: Kevin Reid wrote: FWIW: Common Lisp has rigorously transparent (that is, you cannot observe the machine word size) bigints and quite a few binary operation

Re: Rename Number.prototype.clz to Math.clz

Kevin Reid wrote: FWIW: Common Lisp has rigorously transparent (that is, you cannot observe the machine word size) bigints and quite a few binary operations defined on them, so it's where I personally would look for precedent on such questions. (a) we don't have a bignum type yet; (b) we want

Re: Equality Reform(ul)ation

Brendan Eich wrote: It would be better to repair == by allowing developers to opt string and boolean (note lowercase) into B And number too. Will try to get all this drafted, just not today. /be ___ es-discuss mailing list es-discuss@mozilla.org

Re: Equality Reform(ul)ation

Kevin Smith wrote: It's opaque. If you self-hosted using a Uint32Array of length two (e.g.), you'd have to declare that as the per-instance state for the value class. I didn't show syntax for that -- working on it still. And if you for some reason used floa

Re: Equality Reform(ul)ation

Brendan Eich wrote: Does that mean that the host is somehow able to define "===" semantics for opaque value types (like int64)? Again, I'm assuming that int64 is opaque (i.e. not visibly composed of other elements). It's opaque. If you self-hosted using a Uint32Array

Re: Equality Reform(ul)ation

Kevin Smith January 16, 2014 8:26 AM [oops - reply all this time] Value objects have value, not reference, semantics. JS has string number boolean already (note lowercase names). With value objects, users and the host env can define others. Makes sense,

Re: Equality Reform(ul)ation

On Jan 16, 2014, at 7:38 AM, Kevin Smith wrote: > >>> >>> What's the method for determining whether we run the multimethod dispatch >>> algorithm versus the ES6 abstract equality algorithm? >> >> One or both operands value objects. > > Gotcha. One more, I think. > > int64(0) === 0L > >

Re: Equality Reform(ul)ation

Kevin Smith wrote: js> 0L == { valueOf: function() { return 0 } } typein:2:0 TypeError: no operator function found for == Is the Object-type operand converted to a primitive before the overload is matched? No, the multimethod dispatch algorithm runs. Even with To

Re: Rename Number.prototype.clz to Math.clz

This is a judgment call, I'm with Jason, I think we should revisit. I'm putting it on the TC39 meeting agenda. /be Allen Wirfs-Brock January 15, 2014 11:26 AM So we discussed all that when we made that decision. I understand that you disagree but is there any n

Re: Equality Reform(ul)ation

Andrea Giammarchi wrote: I would expect that to be `true` same as `0 == {valueOf:Number}` would be No, please do read what I posted. Value object operator dispatch is different and does not use toString or valueOf on an object operand. /be ___ es-d

Re: Equality Reform(ul)ation

Kevin Smith wrote: js> 0L == "0" typein:2:0 TypeError: no operator function found for == And what does this do? 0L == { valueOf() { return 0 } } js> 0L == { valueOf: function() { return 0 } } typein:2:0 TypeError: no operator function found for == Is the Object-type

Re: Operator overloading for non-value objects

ber(myLong)); // works On Jan 14, 2014, at 22:50, "Brendan Eich" wrote: Domenic Denicola wrote: Heh, yes, damned if you do, etc. etc. I was trying to think up a practical example where this would cause problems (e.g. in CSS libraries strings and numbers often mi

Re: Operator overloading for non-value objects

Domenic Denicola wrote: Heh, yes, damned if you do, etc. etc. I was trying to think up a practical example where this would cause problems (e.g. in CSS libraries strings and numbers often mix), but all my cases involved an `==`-using third party library, in which case you'd just pass it `Numbe

Re: Operator overloading for non-value objects

Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich > js> 0L == "0" > typein:2:0 TypeError: no operator function found for == Hmm, upon seeing this in action, I'm not sure how I feel about `==` throwing.

Re: Operator overloading for non-value objects

Kevin Smith wrote: What about: 0L == "0" So glad you asked, and you will like the answer: js> 0L == "0" typein:2:0 TypeError: no operator function found for == See http://image.slidesharecdn.com/jsresp-130914140214-phpapp02/95/slide-12-638.jpg?1379296961, For the expression v + u 1.

Re: Operator overloading for non-value objects

Kevin Smith wrote: I'll stop there, because I don't know the details of the proposal. Allowing value objects (and perhaps mutable object) to define operators means giving up some invariants, similar to proxies which can have incoherent has/get etc. So I'm not sure what you are waiting for.

Re: Operator overloading for non-value objects

Kevin Smith wrote: While opinions vary, the fact remains that == and <= are in the language, are loose, and need to be overloadable for useful value objects, specifically more numeric types. I agree, that must be a goal of the design. Suggest you pull == out of your mental p

Re: Operator overloading for non-value objects

Kevin Smith wrote: `0m` is literal syntax, for `decimal(0)`. Where `decimal` is a value type factory. Right - I meant what are the semantics of "===" applied to dissimilar, perhaps "numeric", value types. We worked through this in 2008 when IBM was pushing decimal at ES3.1 (now ES5

Re: Operator overloading for non-value objects

Kevin Smith wrote: Your point about it being too late to salvage == (vs. ===) is good, but perhaps with value objects plus further work to disable implicit conversions, == will make a come-back -- but that's far down the road. Work to disable implicit conversions? Can you cla

Re: ES6 problem with private name objects syntax

Maciej Jaros wrote: So basically one could implement Symbol as something similar to GUID generator, right? It should work even if you simply restart a counter and make sure you don't clash with other stuff and e.g. return "__#symbol#__1", "__#symbol#__2" and so on. No. There must be no way, b

Re: Operator overloading for non-value objects

Thanks for the reply. Domenic Denicola wrote: In JavaScript, our data structures are specified to use SameValue (or SameValueZero, or Strict Equality Comparison); none of them use a user-overridable hook. Furthermore, years of best-practice advice have made a lot of programmers prefer using `

Re: Operator overloading for non-value objects

Anne van Kesteren wrote: On Mon, Jan 13, 2014 at 3:40 PM, Brendan Eich wrote: > We want to keep the relatively few invariants in the language that we have. > Why is it so important to have == for (mutable) URLs? The alternative is rather ugly. You don't want to sometimes writ

Re: Operator overloading for non-value objects

Anne van Kesteren wrote: On Mon, Jan 13, 2014 at 1:13 PM, Dean Landolt wrote: > Value Objects. See the recent thread re: value objects on es-discuss. Slides > from the presentation Brendan linked to > (http://www.slideshare.net/BrendanEich/js-resp) confirm that == will still > be overloadab

Re: Value objects: roll your own?

Andrea Giammarchi wrote: what I meant is that you require('point3d') before requiring point2d .. is that a concern? Is that like the point4d coming along unexpectedly? I don't know what you mean, but in the error example, whichever loads second results in the early error. So what? /be __

Re: Value objects: roll your own?

Andrea Giammarchi wrote: "the call is ambiguous and an error is thrown" .. that's OK, but this is assuming you know upfront all libraries in the game, right? No, this is just a matter of loading point2d's value class declaration, then point3d's. It's fine to have methods defined for various

Re: Value objects: roll your own?

We're not abusing guard :: syntax, are you trying to get my goat? :-P Andrea Giammarchi wrote: recap ... in class point3d ```javascript function + (a :: point2d, b :: point3d) { return point3d(a.x + b.x, a.y + b.y, b.z); } ``` in class point2d ```javascript function + (a :: p

Re: Value objects: roll your own?

Andrea Giammarchi wrote: I had same thoughts on being defined inside the class ... it's quite common out there but here I see it's very easy to create conflicts between classes. What if a generic point2d + point3d is defined in both point2d class and point3d one ? The definitions need to be

Re: Value objects: roll your own?

Axel Rauschmayer wrote: Nice! Should the operator (case) definitions really be inside the class? E.g., conceptually, number + point2d does not belong to a single class, it belongs to both. Or to neither. Still there's an advantage in using the class as the locus of multimethod definitions: al

Re: ecmascript should support multi-threads

Quildreen Motta wrote: The idea of having shared mutable state in a language is a horrifying one. I'm glad JavaScript isn't heading in that direction. Remember, threads suck . /be ___ es-discuss mailing

Re: Code compilation alternative to Function()

fixplzsecr...@gmail.com wrote: Asm.js programs are larger than equivalent native executables Not on the (gzipped) wire: http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html (Emscripten has improved since then, IINM.) In memory, the issue isn't executable vs. JS sou

Re: Enumerability

Brendan Eich wrote: I can only think of cases (including Claude Pache’s pro-enumerability example) where I would want to copy *all* own properties. Why do you want an array's .length to be copied? Or in Claude's example, why should a non-enumerable _parent be copied? Claude

Re: Enumerability

Axel Rauschmayer wrote: I’m sorry for being difficult, but IMO this is an important point: The current cowpath is for-in style, right? That is, inherited and own non-enumerable properties. We’ll deviate from that anyway. Independently of what enumerability means, I can only think of cases (inc

Re: Clarifications on the iterator protocol

David Bruant wrote: "Without Brendan, a champion of iterators and generators, don't have full consensus". Later notes don't come back to this, so I imagine Brendan agrees (upon confirmation, I'll PR the meeting notes to reflect this for future readers). This was settled in person and only ki

Re: Value objects: roll your own?

Axel Rauschmayer wrote: http://www.slideshare.net/BrendanEich/value-objects One thing is not entirely clear from the slides: Will developers be able to define their own value object types? Without that feature I don’t see how overloading operators would be very interesting. That is out of da

Re: Need a champion? StringView strawman

Allen Wirfs-Brock wrote: Another nit: the definition of "ASCII whitespace" is different from the definition of whitespace used by String.prototype.trim [1]. That means that an implementation of this spec. that was implemented using JS couldn't use S.p.trim to process labels as described in th

Re: Enumerability

Axel Rauschmayer wrote: I know this runs counter the conventional wisdom for specs, but I find design rationales incredibly important for making sense of what’s going on: The answers and discussions on this mailing list were essential in helping me understand the language. +1. /be __

Re: Enumerability

Axel Rauschmayer wrote: Nice example. Data versus meta-data, in line with the `length` of an array being non-enumerable. Yes, and that's the primordial reason for enumerability. But it still seems that class declaration users might want methods on the prototype to be non-enumerable. Sauce for

Re: Need a champion? StringView strawman

I think based on bugs and bz's advice the Dwayne has been misled by bad old pre-WebIDL API in Gecko -- there's no reason to do any string-viewing here. Certainly not punning bytes as points in a character set encoding. /be Anne van Kesteren January 11, 2014 8:27 AM

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

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: 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: const VS features detection

Andreas Rossberg wrote: - YAGNI -- I have a hard time coming up with a use case that isn't obfuscated code (even considering generated code). Always a good reason in the abstract, but concrete use cases have arisen, even in this thread. As you noted just last month (!), """ For ES7 I would

Re: Object.is()

Andreas Rossberg wrote: Lacking true integers, that would break JavaScript's poor man's >> emulation of arrays. > > C'mon, that's not the reason. Hardly anyone generates-0 as an index and > expects it to index a[0] for some array a. Things to complain about!:-P It's not all that difficult

Re: Object.is()

Andreas Rossberg wrote: On 23 December 2013 03:17, Alex Kocharin wrote: > > That's something I never really understood when I was reading ES5 spec, where -0 is a special case, and a sole reason why `x === Number(String(x))` is not true for all numbers. NaN is another special case. IEEE equ

Re: const VS features detection

Allen Wirfs-Brock wrote: I had been considering purging that handling from the ES6 spec. but maybe I'll leave it in. Please do! This dates from block-lambda future-proofing days? I dimly recall ES1 drafts having full completion-type abstraction (over all forms, not just statements but also e

Re: const VS features detection

David Herman wrote: On Jan 6, 2014, at 8:10 AM, Brendan Eich wrote: > To further constrain design (since design is mostly about leaving things out), I will address the ES4-era |let (x = y, z = z /* outer z*/) ...| let blocks and let expressions, which came up recently. We should not rev

Re: const VS features detection

David Herman wrote: On Dec 20, 2013, at 5:32 AM, Andreas Rossberg wrote: > For ES7 I would like to revive the do-expression proposal (hopefully > at the next meeting) Glad to hear you're in favor! I'll be happy to co-champion. I will support your prospective championship ;-). To further

Re: Additional Set.prototype methods

Mark S. Miller wrote: Sets and Maps are deterministically ordered by insertion order. I know; my point was whether this should be reduce order (and reduceRight the reverse?). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozil

Re: Additional Set.prototype methods

David Bruant wrote: Hi, I've been playing with Sets recently and believe that the following additions would make them more useful by default: * Set.prototype.map * Set.prototype.filter * Set.prototype.toJSON = function(){ return [...this]; }; The 2 first are to easily create sets from exi

Re: Overly complicated Array.from?

David Bruant wrote: Le 29/12/2013 01:48, Brendan Eich a écrit : David Bruant wrote: it's somewhat ironic that Array carries 'from' given it's the only "class" that doesn't need it per case study for 3) above :-) But Array is the return type. It's alwa

Re: Overly complicated Array.from?

David Bruant wrote: it's somewhat ironic that Array carries 'from' given it's the only "class" that doesn't need it per case study for 3) above :-) But Array is the return type. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozi

Re: Should the default constructor return the return value of super?

Allen Wirfs-Brock wrote: I generally try to avoid early errors that have a lot of conditions associated with them. That's a warning sign in JS specs, indeed. Adding class syntax as (mostly) sugar for the prototypal pattern does not obviously mean rejecting all unusual or exceptional variants

Re: Overly complicated Array.from?

David Bruant wrote: Based on what I suggested (internalize iterators in Array.from code for polyfills), the ES5 equivalent is to override Array.from as such: js (function(){ var nativeArrayFrom = Array.from; Array.from = function(x){ if(/*x is of my library type*/){

Re: Should the default constructor return the return value of super?

Claude Pache wrote: I agree that `constructor(...args){ return super(...args); }` is better (i.e. less surprising) when the super-class's constructor returns an other object than `this`. However, under the current state of the specification, there is at least one exception: the `Object` constr

Re: es-discuss Digest, Vol 82, Issue 98

raul mihaila wrote: I am beginning to like the syntax from ES4. I suppose it would work with multiple variables as well. let (x = x, y = y, z = x + y /* maybe would work? */) { } Yes, ES4 let expr/block works with multiple declarators in a comma-separated list in the head. Perhaps it

Re: Fwd: local variables with inherited values

raul mihaila wrote: What I want is both similar to A2 and B2, but it's different in that there is only 1 scope for the inner variable. There is only one inner scope for the braced block in Waldemar's example, in any of {A,B}{1,2}: let x = "outer"; function g() {return "outer"} { g(); fu

Re: local variables with inherited values

ES4 had let (x = x) ... forms (where ... was an expression or a body), but for ES6 we agreed on the temporal dead zone: { let x = 'outer'; { /* x throws here */; let x = 'inner'; alert(x); } alert(x); } which will alert 'inner' then 'outer'. There is no way to initialize the inner x from t

Re: Deep Object Observing

Eric Devine wrote: The recursive function to accomplish this is simple enough, but the memory footprint has the potential to become expensive when scaled. I feel this feature is a good candidate for a native implementation. Is there any plans to bring the concept of deep object observing to ES

Re: `String.prototype.contains(regex)`

Mathias Bynens wrote: It seems that `contains` was forgotten about whenhttps://bugs.ecmascript.org/show_bug.cgi?id=498#c3 was fixed, so I’ve filedhttps://bugs.ecmascript.org/show_bug.cgi?id=2407 asking to make `String.prototype.contains(regex)` throw as well. Thanks! /be _

Re: Object.is()

IMPORTANT TYPO ALERT! Brendan Eich wrote: No language stringifies -0 as "0" I meant "-0". that I know of. IIRC, IEEE-754 recommends against doing that. Stringizing is not for serialization, rather for human consumption in general, and -0 === 0. ... jetlagged again

Re: Object.is()

Alex Kocharin wrote: That's something I never really understood when I was reading ES5 spec, where-0 is a special case, and a sole reason why `x === Number(String(x))` is not true for all numbers. Why isn't it stringified as "-0"? How did that happen? Do somebody really check if something is

Re: Object.is()

Mark S. Miller wrote: Object.isz = (x, y) => x === y || Object.is(x, y); Not bad. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Object.is()

Alex Kocharin wrote: Object.is() looks like a perfect function for checking oddballs (-0, NaN) if you want to represent an arbitrary data correctly. In that case distinguishing signed zeroes is a big plus or absolutely required. (making (-0).toString() === '-0' would be better though). (No

Re: Object.is()

Domenic Denicola wrote: If the belief is truly that SameValueZero is more useful than SameValue, perhaps we should consider relaxing that restriction, and allowing people to flip the sign of non-writable zero-valued properties? You are reasoning from general to particular, but without any rea

Re: Object.is()

We talked about this at the last last TC39 meeting. I joked about adding Object.isz, or (in honor of @izs) Object.izs. But we didn't add anything. You can write it yourself, of course (just modify the Object.is polyfill). /be Axel Rauschmayer December 22, 2013 1:00

Re: const VS features detection

On Dec 20, 2013, at 5:29 PM, Andrea Giammarchi wrote: > Anyway, got it, nothing will change, it would be very cool to think about > improving try/catch logic in any case, but that's another topic. It is a good use-case for do expressions, for sure. /be _

Re: const VS features detection

Andrea Giammarchi wrote: I am suggesting that const should: 1. reserve the const name for the whole scope (similar to var) 2. if assigned, keep that value and throw if re-assigned 3. if not assigned, having the very first assignment "seal the deal" and throw to any other re-assignment att

Re: const VS features detection

Andrea Giammarchi wrote: why is this not possible, giving the ability to understand through typeof if there is a value or not? ```javascript // defined as const // reserved in this scope // but not assigned yet const WHATEVER; if (condition) { // first come, first serves WHATEVER = 123; /

Re: Object.assign with several source objects

Angus Croll wrote: the alternative is that the second argument expects an array of 1 to n source objects. This works with reduce and leaves way clear for future 3rd argument (eg deep copy boolean) Mandatory array-of-parameters is an anti-pattern, given spread. Even if the allocation costs not

Re: Object.assign with several source objects

c].reduce(Object.assign)` code in the wild that implicitly passes an index as the third parameter and the whole array as the fourth parameter. -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Tuesday, December 17, 2013 20:18 To: Claude P

Re: Object.assign with several source objects

It's now or never. I agree multiple sources are useful enough to do now; I don't see a different third parameter that would be precluded by deciding this. But others may disagree. /be Claude Pache December 17, 2013 5:06 PM Hello, Tonight, when playing with ES6

Re: read only names

raul mihaila wrote: Btw, are private names still in? I couldn't find them in the html version of the latest draft. You can tell that private names are *not* in by noticing the strawman: namespace in the wiki, not the harmony: namespace. http://wiki.ecmascript.org/doku.php?id=strawman:private

Re: Reserving await within Arrow Functions

Tab Atkins Jr. wrote: On Thu, Dec 12, 2013 at 11:41 PM, Brendan Eich wrote: > John Barton wrote: >> >> offline Mark lured me in to making more suggestions. I bit: >> >> p1>< foo(a,b); // p1 "eventually when the sand runs out" foo(a,b); >>

Re: Reserving await within Arrow Functions

Grrr, something stripped leading spaces. Trying again. /be - public

Re: Reserving await within Arrow Functions

John Barton wrote: offline Mark lured me in to making more suggestions. I bit: p1 >< foo(a,b); // p1 "eventually when the sand runs out" foo(a,b); p1 <> foo(a,b); // Because a wikipedia page has diamond for temporal logic 'eventually'. I guess angle brackets in general are trouble however, I

Re: Reserving await within Arrow Functions

Kevin Smith wrote: 1) Non-mapping iteration (e.g., `forEach()`) 2) Lightweight callbacks Or, mappings to void. Good point -- forEach is an explicit and more efficient map with garbage result full of undefineds. 3) Killing off 90% of `var self = this` occurrences. Here's is

Re: Reserving await within Arrow Functions

Mark S. Miller wrote: Putting aside my immediate esthetic reaction, I suggest we consider one of =>, *=>, !=> We went over these at the last TC39 meeting. The *=> and !=> forms are future-hostile to elided empty parameter list for arrow. =>, =*>, =!> We didn't consider these car

Re: Reserving await within Arrow Functions

Alex Russell wrote: The issue with 'await' is: apart from sequence vs. mapping, given that arrows have a limited Tennent's Correspondence Principle for not only |this| and |super|, is it confusing to have |arguments|, |yield|, and |await| not mean outer "bindings", vs. inner? N

Re: Reserving await within Arrow Functions

Kevin Smith wrote: My thoughts: Again, generators are not a good fit for arrows - generators define sequences, not mappings. Yep. Secondly, we should be conservative in our usage of arrow-like operators - we only have so many decent looking things left! What's more, ~ has nothing to do wi

Re: Reserving await within Arrow Functions

Brendan Eich wrote: But to recap the TC39 meeting discussion, we do not believe we can add =>* or =>! -- the latter is arrow with a unary logical negation expression as the body. Other places to put the * and ! are problematic due to ASI. So what exactly are we gonna do for async arro

Re: Reserving await within Arrow Functions

But to recap the TC39 meeting discussion, we do not believe we can add =>* or =>! -- the latter is arrow with a unary logical negation expression as the body. Other places to put the * and ! are problematic due to ASI. So what exactly are we gonna do for async arrows, if anything? We said no/de

Re: Reserving await within Arrow Functions

Rick Waldron wrote: On Wed, Dec 11, 2013 at 5:31 PM, Brendan Eich <mailto:bren...@mozilla.com>> wrote: Thanks for bringing this up -- it's a good point. Unlike ES5 strict and 'yield', the cat is not yet out of the bag. We need to commit, though. I suspect

Re: Reserving await within Arrow Functions

Thanks for brining this up -- it's a good point. Unlike ES5 strict and 'yield', the cat is not yet out of the bag. We need to commit, though. /be Kevin Smith December 11, 2013 1:00 PM I think we should at least consider for a moment reserving `await` within the b

Re: toLocaleString in Object and Array

Claude Pache wrote: In conclusion, among the three proposed solutions, the second one should be avoided because of the issue of inconsistent localisations. The third one seems reasonable because it allows `Array.prototype.toLocaleString` to be properly specified by ECMA-402. +1. /be ___

Re: “Arrow is not a replacement for all functions that want lexical this”

Andrea Giammarchi wrote: FWIW, function [A-Za-z_] includes `var expr = function expr() {}` or `{expr: function expr(){}}` both quite common patterns (the first one when you want to be able to debug the name of the function but due inline, later on, features detection, the former might change) S

<    3   4   5   6   7   8   9   10   11   12   >