Default operator strawman - ||| rather than ??

In the current default operator strawman[1], the operator is ??, e.g.: a = b ?? 5; is shorthand for a = b !== undefined ? b : 5; Would it be possible to use ||| instead? E.g.: a = b ||| 5; I ask because I was planning (prior to knowing about this strawman!) to suggest that, along with a diffe

Re: Rest parameter syntax

On 12 June 2012 16:42, Herby Vojčík wrote: > >> But I understand there are problems. First, what with optional params > after ...rest. And the second, how to parse it when foo(1, 2) called? > > I would think with function foo(a, b, ...others, c) { } then given foo(1, 2); ...within foo a is 1,

Re: Rest parameter syntax

On 12 June 2012 17:03, Herby Vojčík wrote: > function foo (a, b, ...rest, c, d) { ... } > foo(1, 2, 3) > > What here? > > Yes, [1, 2, [], 3, undefined] is probably the most logical one. But then d > is not the last one (yes, it is only last one when there is at least four > of them). > Yeah, I w

Re: Rest parameter syntax

On 12 June 2012 17:21, Felix Böhm wrote: > As written before: > > function foo(a, b, ...others, c){ … } > > behaves the same as > > function foo(a, b, ...others){ > var c = others.pop(); > } > Sadly, it's not as simple to emulate function foo(a, b, ...others, c, d) { } ...using pop. But obvi

Re: Rest parameter syntax

On 12 June 2012 18:00, Brendan Eich wrote: > T.J. Crowder wrote: > >> And yet, if not yet implemented in its current form (I have no idea what >> the extent of implementation is), the complexity increment does not seem >> large. > > > Here you went down the

Re: Rest parameter syntax

On 12 June 2012 18:14, Brendan Eich wrote: > Red guy still on your shoulder :-P. I think you're seeing things. ;-) But seriously, I don't really have a horse in this race (at all, I was just exploring the concept -- seems that's already been done), happy to leave it at that. -- T.J. __

Re: ||= is much needed?

On 13 June 2012 06:52, Brendan Eich wrote: > People don't default on the caller side (at the callsite) much, in my > experience. Dave may be seeing other sources, but it's extremely rare in my > experience to see > I'm with Dave on this, I do it fairly regularly, usually when a function turns ar

Re: Would some like Object.inspect(myObj) be useful?

On 14 June 2012 10:42, Hemanth H.M wrote: > Was just wondering if something like *Object.inspect(myObj) *would give > all the attributes of that particular object. > Is there a proposal or strawman you're referring to? I'm not immediately seeing it, but I'm still new here. PrototypeJS has an Obj

Re: Would some like Object.inspect(myObj) be useful?

On 14 June 2012 11:07, Hemanth H.M wrote: > No there is no proposal of that I'm aware of in Strawman, just asking the > group if it's useful? > I can't speak for the group, but I think you'd need to explain it a lot more. :-) What would it return? How does it relate to the existing reflect_api h

Re: ||= is much needed?

On 14 June 2012 18:10, Brendan Eich wrote: > I agree on reflection with Wes and others who've objected that A ?: B has > the simplest interpretation as A ? A : B and therefore should not be used > for anything like (A !== undefined) ? A : B or (A != null) ? A : B. I noted > this as an open issue

Re: ||= is much needed?

On 14 June 2012 19:01, Brendan Eich wrote: > The users who want null to be distinct from undefined are neither > CoffeeScript users, nor || users (in their defaulting code). They must be > doing === undefined test. > Not quite. I use || whenever I can in my defaulting code, and I can use it a lo

Re: ||= is much needed?

On 14 June 2012 21:45, Brendan Eich wrote: > I can see adding ?? and ??= (undefined-only, not undefined-or-null). > Excellent. > Is ||= really worth it? It would not assign if the left side is truthy, > but perhaps no one will mind. > Nice-to-have. The fact it doesn't assign if the left side

Re: ||= is much needed?

On 14 June 2012 22:38, John Tamplin wrote: > On Thu, Jun 14, 2012 at 5:32 PM, T.J. Crowder wrote: > >> >>> Is ||= really worth it? It would not assign if the left side is truthy, >>> but perhaps no one will mind. >>> >> >> Nice-to-have. The f

More fun with undefined

Making a point of making this a separate thread from the current ?? and ??=thread(s), which are thankfully looking close to consensus. So that's infix and assignment. Question: Should we consider unary as well? I ask because I went searching through my code (and others') to see where I'd get a lo

Re: More fun with undefined

On 14 June 2012 23:10, T.J. Crowder wrote: > The rule is simple: & evaluates true if its argument is undefined, false > otherwise: > Slip of the fingers there. £, obviously. Not &. And again, the symbol is unimportant for now. -- T.J. _

Re: More fun with undefined

On 15 June 2012 07:42, Herby Vojčík wrote: > > > T.J. Crowder wrote: > >> Making a point of making this a separate thread from the current ?? and >> ??= thread(s), which are thankfully looking close to consensus. So >> that's infix and assignment. >> >

Re: More fun with undefined

On 15 June 2012 08:09, Andreas Rossberg wrote: > On 15 June 2012 01:22, Allen Wirfs-Brock wrote: > > A wonder if this wart is hairy enough, that we wouldn't be justified in > some > > explicit backwards compatibility hackery in the spec. to remove it. > > > > For example, we could allow it to ap

Re: More fun with undefined

On 15 June 2012 12:41, Brendan Eich wrote: > This isn't unrelated. If we do get patterns into Harmony they may subsume > some of the postfix-?? (which does not work syntactically, IMHO) or > prefix-? ideas. Or at least prefix-? may show up in the pattern language > (dherman and I have discussed i

Re: Default operator strawman - ||| rather than ??

I think the original thrust of this thread may have got lost a bit in the (useful) discussion of null and undefined, so coming back to the original point: On 12 June 2012 16:29, T.J. Crowder wrote: > In the current default operator strawman[1], the operator is ??, e.g.: > > a = b ??

Re: More fun with undefined

On 15 June 2012 14:34, Aymeric Vitte wrote: > Example : > > console.log(a);//Reference error, GetBase returns undefined > > console.log(window.a);//undefined > > --> does not seem very logical, no ? > To me this would be a big step backward, after the very large stride forward this group made in

Re: More fun with undefined

On 15 June 2012 15:34, Aymeric Vitte wrote: > I am not talking about defining implicit properties or such things, > neither having undeclared stuff looking declared, but just changing the > behavior of retrieving a property when base is undefined, which will then > be undefined. > > If am I read

Re: RegExp.escape()

On 23 March 2012 12:12, Steven Levithan wrote: > Erik Corry wrote: > > In perl the recommended version is > > > > text.replace(/([^a-zA-Z0-9])/g, "\\$1") > > > > which is future-proof and safe and I think this also works for JS. > > It's probably future-proof and safe, but it escapes 65,520 charact

Re: More fun with undefined

On 15 June 2012 17:00, Aymeric Vitte wrote: > Right now I am not proposing but trying to understand why it is like this > Sorry, I thought you were proposing something. Your first message talked about changing how GetValue works, apologies if I misunderstood. Brendan could speak FAR better to

Re: Default operator strawman - ||| rather than ??

On 15 June 2012 18:05, Erik Arvidsson wrote: > Since you are asking for opinions. > > I don't want it. It doesn't carry its own weight. > I was, and that includes opinions against. Thanks! -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: Default operator strawman - ||| rather than ??

On 15 June 2012 22:22, Brendan Eich wrote: > If everyone's opinion carries weight, then we are tied :-P. Kidding. > > But aside from opinions and their weight, we have a problem if "wouldn't > hurt" is the answer for syntax proposals. Who said it was? New syntax does hurt. It hurts by requirin

Re: Default operator strawman - ||| rather than ??

On 16 June 2012 01:44, Brendan Eich wrote: > T.J. Crowder wrote: > > On 15 June 2012 22:22, Brendan Eich > bren...@mozilla.org>> wrote: >> >>If everyone's opinion carries weight, then we are tied :-P. Kidding. >> >>But aside from

Re: catch vs function scope; var declaration vs initialization

> > Inside the catch, the catch-scope is first for reading and writing. > But the catch scopes are ignored for declaring new variables. So your > expectation seems to be the correct one. That was my analysis as well. §10.5 tells us that `var` creates bindings in the anonymous function's environm

Re: String.prototype.contains and Set|Map.prototype.has naming consistency.

Agree w/Tobie on both points (consistency btw String and Set/Map, and having it on Array as well). FWIW, prefer `contains` to `has`. -- T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com On 20 May 2012 10:46, Tobie Langel wrote: > Hi, >

Re: Classes as Cosntructors

n contexts and scope by making it seem like the constructor arguments would be in-scope throughout, when presumably they wouldn't. I'm not keen on introducing new magic to execution context definition if we can avoid it, and I think we can avoid it here. FWIW, -- T.J. Crowder Independent S

Re: announcing normative ECMAScript specification in HTML

(or changed) would be useful. If TC39 needs volunteers to come up with the set of semantically-intelligent targets, sign me up. Best, -- T.J. Crowder tj / crowder software / com www / crowder software / com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: TC39 meeting Wed 5/23/2012

one that throw even in non-strict mode. Far better to have a consistent view of read-only properties within a given execution context, where the author decides whether they want silent failures or exceptions. -- T.J. Crowder Independent Software Engineer tj

Re: TC39 meeting Wed 5/23/2012

On 28 May 2012 17:34, John J Barton wrote: > > On May 28, 2012 2:53 AM, "T.J. Crowder" wrote: > > > > On 28 May 2012 06:37, John J Barton wrote: > >> > >> A library writer creates an object in one scope and all of their tests > >> succeed.

Re: TC39 meeting Wed 5/23/2012

On 28 May 2012 18:46, Russell Leggett wrote: > Perhaps this discussion would be aided by a more concrete example. >> > Doh! Excellent idea. John, if you'd like...? (Otherwise I can do one.) -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org htt

Re: New Object Extension Literal Strawman

On 29 May 2012 17:59, Nicholas C. Zakas wrote: > var element = document.getElementById("**myDiv"); > element.{ >innerHTML: "Hello world!", >className: "enabled" > }; > > Going by the current definition, this code block would actually have no > effect because it would be defining new own p

Re: TC39 meeting Wed 5/23/2012

On 29 May 2012 19:26, Jussi Kalliokoski wrote: > I just wanted to add more weight to the fact that frozen objects aren't > really the only objects you can't write to; it's the same with primitives > (string, number, etc) as well, and all of them fail silently, it's very JSy > to fail silently on

Re: New Object Extension Literal Strawman

On 30 May 2012 05:09, Brendan Eich wrote: > Brendan Eich wrote: > >> The only usable+secure extensions I see are two, so we don't confuse >> users with almost-identical syntax with quite different (when it matters >> most, when under attack) semantics: >> >> A. obj.{prop: val, ...} as safe mustac

Re: New Object Extension Literal Strawman

On 31 May 2012 10:44, Andreas Rossberg wrote: > On 30 May 2012 23:34, David Herman wrote: > > On May 30, 2012, at 2:27 PM, Rick Waldron wrote: > > > > On Wed, May 30, 2012 at 5:22 PM, David Herman > wrote: > >> > >> > >>array.{ > >>pop(); > >>pop(); > >>pop(); > >>

Re: New Object Extension Literal Strawman

On 31 May 2012 11:05, Jussi Kalliokoski wrote: > On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder > wrote: > >> On 31 May 2012 10:44, Andreas Rossberg wrote: >> >>> On 30 May 2012 23:34, David Herman wrote: >>> > On May 30, 2012, at 2:27 PM, Rick Waldr

Re: New Object Extension Literal Strawman

On 31 May 2012 11:18, T.J. Crowder wrote: > On 31 May 2012 11:05, Jussi Kalliokoski wrote: > >> On Thu, May 31, 2012 at 12:52 PM, T.J. Crowder >> wrote: >> >>> On 31 May 2012 10:44, Andreas Rossberg wrote: >>> >>>> On 30 May 2012 23:34, D

`with` revisited and related to object extension literals

All, I was going to lurk longer before raising this, and apologies if it's been raised before, but the discussion of object extension literals sort of brought it up. TL;DR: I wonder if the object extension literal might reasonably become a fit-for-purpose `with`. For years I've thought the `with`

Re: New Object Extension Literal Strawman

On 31 May 2012 11:30, François REMY wrote: > o.{ >>a.b = 6; >>c.f(); >>a.b = a.c; // !! >> }; >> > > This is indeed an issue that could be solved using > > o.{ > .a.b = 6; > .c.f(); > .a.b = .a.c; > } Exactly my thought, and as it happens I was just writing it

Re: `with` revisited and related to object extension literals

On 31 May 2012 11:33, T.J. Crowder wrote: > All, > > I was going to lurk longer before raising this, and apologies if it's been > raised before, but the discussion of object extension literals sort of > brought it up. > > TL;DR: I wonder if the object extension literal

Re: `with` revisited and related to object extension literals

On 31 May 2012 12:12, Andreas Rossberg wrote: > On 31 May 2012 12:52, T.J. Crowder wrote: > > 2. I originally envisioned this as a statement (of course, I was > originally > > thinking we'd have a new keyword, until the object extension literal > > discussion), but

Re: `with` revisited and related to object extension literals

On 31 May 2012 19:24, David Herman wrote: > On May 31, 2012, at 4:12 AM, Andreas Rossberg wrote: > > >> 4. The leading dot seems, to me, to be more explicit than just having > the > >> first symbol on the left being implicitly a property the object. EIBTI > > > > I agree with that. > > As I said

Re: `with` revisited and related to object extension literals

On 31 May 2012 22:17, Rick Waldron wrote: > > > On Thu, May 31, 2012 at 4:46 PM, T.J. Crowder wrote: > >> On 31 May 2012 19:24, David Herman wrote: >> >>> >>> As I said in another thread, it's not going to happen because of the ASI >>> ha

Re: New Object Extension Literal Strawman

On 31 May 2012 19:21, Brendan Eich wrote: > Thanks, Dave. > > Bottom-citing here, and again I'm a sinner too, but could everyone on this > nicely long thread take a breath and remember two things: > > 1. We aren't going to reform 'with' for ES6 or Harmony. It's banned in > strict mode, there due

Re: `with` revisited and related to object extension literals

On 1 June 2012 00:28, Brendan Eich wrote: > In the with example that Dave gave: > >with (obj) { >foo() // no semi >.bar = 12 >} > > > it's all allowed as in no syntax error (to correct via ASI) and no > restricted production (to make line termination significant). > > Over

Re: `with` revisited and related to object extension literals

On 1 June 2012 00:51, Brendan Eich wrote: > Dave's cascade proposal: > > http://blog.mozilla.org/**dherman/2011/12/01/now-thats-**a-nice-stache/ Thanks. With a great deal of respect, I'm not seeing how that isn't "with-lite" w

Re: `with` revisited and related to object extension literals

On 1 June 2012 01:40, Brendan Eich wrote: > Let's be precise. You keep bringing 'with' up but it's not relevant to the > cascade proposal, going by Dave's definitions. If you have the "appearance > of 'with'" concern I call out above, let's argue about that. It's a good > one (again it is why I p

Re: `with` revisited and related to object extension literals

On 1 June 2012 03:23, David Herman wrote: > There is *no* mixing of scope and object lookup in the cascade proposal. > None at all. > You're talking the technical details. I'm talking appearance and expectation in the eyes of developers. > Just please stop saying that it's like `with`. It's to

Re: `with` revisited and related to object extension literals

On 1 June 2012 06:05, Brendan Eich wrote: > Brendan Eich wrote: > >> you're just rehashing a concern based on appearances >> > > which (I want to be clear; sorry for harshing on the 'with' point) is a > valid concern. We should discuss it directly, no 'with'-semantics mixed in. > > /be > Yes, ve

Re: `with` revisited and related to object extension literals

On 1 June 2012 18:02, David Herman wrote: > I just take issue with the over-broad analogy to `with`. The problem with > `with` is that it's statically undecidable whether any variable in the body > is bound by the object or by something else in the scope chain. > Yeah, at least, it is with JS's

Re: time to trim mustache

On 5 June 2012 21:30, Irakli Gozalishvili wrote: > I just want to (re)express my (and many others) concern about new syntax. > While > Object.extend adds useful feature (Although I think Object.define would be > more appropriate name) I don't think new syntax is really necessary. I do > think t

Re: Error stack

On 8 June 2012 04:28, David Herman wrote: > - You mentioned that compatibility requires error.stack to be a string, > even though programs would really like to have a structured version. Should > we offer a different property with structured stack frame info (probably > with a getter to allow str

Re: Error stack

On 10 June 2012 22:31, Erik Arvidsson wrote: > The thing is that software on the open web has to handle two different > formattings already to work correctly. The reason I picked the V8 > style over the SpiderMonkey style is that the SpiderMonkey style is > missing essential information like the

Re: Error stack

On 10 June 2012 22:44, Oliver Hunt wrote: > My original implementation in JSC was as an Array, but I found that there > were sites that depended on .stack being a string if it was present. Any > form of string encoding we expect to be machine parseable by necessity will > require escaping and fu

RE: name anonymous functions on property assignments

About a year ago, Bergi asked[1] why no name is assigned to a function when it's created as part of an assignment to an object property: o.method = () => { }; Allen Wirfs-Brock replied: > We did not have consensus on doing the same for: > `MemberExpression.IdentifierName = FunctionExpression` or

Re: Accesssing ES6 class constructor function

On Thu, Jan 5, 2017 at 5:31 PM, James Treworgy wrote: I can't address your questions about "why" (I wasn't plugged into the discussions around it), but addressing this: > This has come into play lately for me, as an DI container we use that > does exactly this doesn't work with ES6 classes (and

Re: Accesssing ES6 class constructor function

Apologies, my email was apparently slow and I didn't see your reply to Oriol. On Thu, Jan 5, 2017 at 6:28 PM, James Treworgy wrote: (slaps forehead) this might - actually - be enough. I need to think about > it a bit. The issues of concern are: ability to name the resulting class > dynamically (

Re: Accesssing ES6 class constructor function

On Thu, Jan 5, 2017 at 7:21 PM, James Treworgy wrote: > > Can you clarify what prevents it from being made to work? > > The fundamental feature difference (continuing to think about this!) is that > with ES5 constructors, I can create an instance of something from an abitrary > constructor provid

Re: Accesssing ES6 class constructor function

Note: Related discussion of calling class constructors here: https://esdiscuss.org/topic/determine-if-a-value-is-callable-constructible On Fri, Jan 6, 2017 at 12:11 PM, James Treworgy wrote: > T.J. Thanks for the very thoughtful analysis. But I keep coming back to > this: > >> since we >> wouldn

Re: name anonymous functions on property assignments

tional.org/ecma-262/7.0/index.html#sec-assignment-operators-runtime-semantics-evaluation). -- T.J. On Tue, Dec 13, 2016 at 9:03 AM, T.J. Crowder wrote: > About a year ago, Bergi asked[1] why no name is assigned to a function > when it's created as part of an assignment to an object p

Re: Proposal: Improve syntax for inline anonymous class instantiations

Two aspects to this: Motivations and syntax. ## On motivations: Addressing new syntax, the first question has to be: Is this use case sufficiently common and painful that it needs new syntax? The answer may be yes, but we need to ask the question. Trying to solve it without new syntax with a hel

Re: getOwnPropertyDescriptor side effects

So to sum up, then, and circle back to Francisco Tolmasky's original question: * For ordinary objects, `Object.getOwnPropertyDescriptor` shouldn't have side-effects because none of the ordinary operations it uses has side effects. * For exotic objects, it may well have side effects as a result of

Re: name anonymous functions on property assignments

I'm mistaken about Step 1.e of [assignment evaluation][1], it's not that we'd want to remove the IsIdentifierRef check, it's that we'd want to make it "IsIdentifierRef is true or IsPropertyRef is true": > e. If IsAnonymousFunctionDefinition(AssignmentExpression) is true and either > IsIdentifierR

Re: Idea: Reflect.hasExternalReference

I think the point is that immutability syntax would apply to the use case you've described, because if the object passed is immutable, it doesn't matter whether the sender has a reference to it or not. The receiver can use it without caring, and without making a defensive copy, since it's immutable

Re: Idea: Reflect.hasExternalReference

ct.isMutable` is available since a method, internally, > wouldn't know which syntax has been used to send that argument. > > > > On Sun, Jan 15, 2017 at 2:26 PM, T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: > >> I think the point is that immutabil

Re: Determining if an object can be constructed

Related: There's [a proposal][1] for `Reflect.isConstructor` (and `Reflect.isCallable`) which addresses this very gap. There seem to be some questions around `Reflect.isCallable` (whether it should be true or false for class constructors, since you can't [[Call]] them), but I didn't see issues rais

Re: Proposal for a static constructor and static member variables

It's an interesting idea and certainly some other languages (Java, C#), have static constructors; others (C++) have lived without. I don't recall the runtime details for C#, but certainly Java defers calling static constructors until actually initializing the class, which is indeed later than Java

Re: name anonymous functions on property assignments

Two questions on the minor issue of the following not assigning a name to the function: ```js obj.foo = function() { }; ``` 1) Am I correct that the only reason it doesn't (in spec terms) is that Step 1.e. of [Runtime Semantics: Evaluation](https://tc39.github.io/ecma262/#sec-assignment-operators

Re: name anonymous functions on property assignments

On Fri, Jan 27, 2017 at 4:56 PM, Jordan Harband wrote: > I'd have an objection. Function name inference has already broken my code - > luckily only tests so far, that i know of - and doing it more often would > break more of it. :-) Sorry to hear that. The ship has sailed on function name inferen

Re: name anonymous functions on property assignments

On Sat, Jan 28, 2017 at 3:46 PM, Allen Wirfs-Brock wrote: > > > > On Jan 27, 2017, at 7:26 AM, T.J. Crowder > > wrote: > > > > Two questions on the minor issue of the following not assigning a name > > to the function: > > > > ```js > > obj

Re: Short Comparing proposal

The chief advantage I see to doing this with syntax is short-circuiting. Otherwise, you could use a helper function to achieve `if (valueIn(object.property.secondProp, 'a', 'b'))` quite readily. Short-circuiting makes this interesting, though I worry about it pulling its syntactic weight. If the m

Re: Short Comparing proposal

On Wed, Feb 1, 2017 at 7:06 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Interesting. Would it play well nested too? > > ```js > if (x === 2 || (x === 3 && y === 1)); > > // as > > if (x === (|| 2, (&& 3, y === 1))) > ``` > ? > :-) I think at that point we're just creating an a

Re: Short Comparing proposal

On Wed, Feb 1, 2017 at 7:18 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > I understand, but you can also ternary within a ternary so why would this > have different capabilities ? > Because `if (x === (|| 2, (&& 3, y === 1)))` is trying to use only *half* of the expression within

Re: Short Comparing proposal

On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling wrote: > This is an interesting concept, but reuse of ()'s and : will make it > difficult to pin down, scale to other operators and communicate. Really > the "inclusion" operator needs to be something that stands out, doesn't > break existing spec,

Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

On Thu, Feb 2, 2017 at 12:19 PM, Michał Wadas wrote: > Right now this code: > > Object.setPrototypeOf(Object.prototype, Object.create(null)) > > throws in both Chrome and Firefox. I couldn't find any mention of special > [[SetPrototypeOf]] of %ObjectPrototype%, did I miss something? > Yes. :-) Yo

Re: Is it spec-compliant to forbid setPrototypeOf(Object.prototype, foo)?

On Thu, Feb 2, 2017 at 12:38 PM, Michał Wadas wrote: > Thanks, I erroneously looked at ES2015 spec that calls Object.prototype > ordinary object. > > The Object prototype object is the intrinsic object %ObjectPrototype%. The > Object prototype object is an ordinary object. > The value of the [[Pr

Re: Short Comparing proposal

On Fri, Feb 3, 2017 at 6:51 PM, Bob Myers wrote: > I'm puzzled about what's wrong with the good old `[a, b].some(x => x === > object.property.secondProp)`. If you insist on sugarizing this (but why?), > then it could be `[a, b].some(=== object.property.secondProp)`, or even > `[a, b].||(=== objec

Re: Short Comparing proposal

On Fri, Feb 3, 2017 at 8:29 PM, Bob Myers wrote: > If you're worried about short-circuiting, then > > ``` > [() => a, () => b].some(x => c === x()) > ``` > Obviously, you're not telling anyone anything they don't know there. But as it's both ugly and inefficient... -- T.J. _

Re: Array Comprehensions

Given `Array.prototype.filter`, `Array.prototype.map`, and other utilities you can create combined with arrow functions, what is it about using syntax for this instead that draws you? For me, the syntax doesn't add any expressiveness, e.g. I don't see that this: ```js const numbers = [1, 2, 3]; co

Re: Written Proposal for "package" Keyword for ES20XX Imports

pposed to what Babel does, since of course Babel while excellent is working with some limitations...? -- T.J. Crowder ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Would it be possible to add “await on first use” to the language?

On Fri, Feb 24, 2017 at 5:18 AM, Šime Vidas wrote: > To clarify, the idea is to declare and kick off all the concurrent tasks > upfront (using local variables and the ‘lazy await’ keyword), and then just > continue writing the rest of the code ‘as if all the promises are > resolved’. The async fu

Re: Proposal: a more consistent and stricter number converting function - Number.of()

> > * If you know that your input is either a string or null/undefined (e.g., > as the result of `someHTMLElement.getAttribute('foo')`), you could use > `Number.parseFloat()`, which will produce NaN for the empty string, null > and undefined. > Of course, `Number.parseFloat("23.4ducky")` results

Re: Would it be possible to add “await on first use” to the language?

On Fri, Feb 24, 2017 at 6:35 PM, Šime Vidas wrote: > Domenic's version using current `async`/`await` syntax is nice and clear >> (one might tweak the variable names a bit to differentiate promises from >> resolved values, but...). >> > > This is the issue I have with this approach. The author is

Re: Do settled promise chain handlers fire in the same turn?

On Sat, Feb 25, 2017 at 7:22 PM, /#!/JoePea wrote: > I'm not sure what's the best way to phrase the subject (please advise on the terminology) Re terminology: I think you mean, will they all fire in the same job? (More on jobs and job queues: https://tc39.github.io/ecma262/#sec-jobs-and-job- queu

Re: Standardize global `setTimeout`/etc.?

On Sun, Feb 26, 2017 at 1:20 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > These are standard already: > https://www.w3.org/TR/2011/WD-html5-20110525/timers.html#timers That's only for browsers. As far as I know, there's no standard for the broader picture Isiah was talking about.

Re: Feedback on Iterable Numbers Proposal?

On Sun, Feb 26, 2017 at 7:40 PM, kdex wrote: > On that note, it might make more sense to add range literals. > That was my thought as well -- or at least, ranges if not range literals. (A simple `Range` is trivial to implement, but I'd rather see something ubiquitous.) I don't see any active, in

Re: Do settled promise chain handlers fire in the same turn?

On Sun, Feb 26, 2017 at 7:49 PM, /#!/JoePea wrote: > > Thanks T.J., that explains it well. Glad that helped! > I asked because I'm working with synchronous tests, so I'm wondering > how to resolve ES6 Promises with fake network data synchronously, > and fire all the handlers synchronously, all w

Re: await setTimeout in async functions

ur second one, though, is nice and simple. Using Jérémy's `delay`, it looks like this: ```js const asyncFunc = (...args) => delay(1000).then(() => computeResult(...args)); ``` -- T.J. Crowder ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: await setTimeout in async functions

omputeResult` could happen later > on? > Okay. With respect, that sentence is *really* unclear, esp. given the context that it was obvious from the example that it's important that `computeResult` isn't called until after the delay. But we

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 12:43 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Not the first time I accidentally type the following: > > ```js > const allTheThings = await [pa, pb, pc]; > ``` > > I am assuming that JS will implicitly realize that'd be a > `Promise.all([pa, pb, pc])` cal

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 3:28 PM, Matthew Robb wrote: > > I think this conversation needs to happen but I am not sure baking > it into Array facilities makes the most sense. > > In my experience with async/await I am very often needing Promise.all but > in some cases the other forms of multi promise

Re: How about awaiting Arrays ?

On Fri, Mar 3, 2017 at 4:51 PM, Michał Wadas wrote: > Actually I would go with > > await ...expr; > > As sugar for: > > await Promise.all(Array.from(expr)) Which is great for `Promise.all`, but leaves us without `race` or things that may be added in future (like Andrea's `any`). (Granted `all` ha

Re: Question ... perhaps a proposal: extract from object to object

```js > _.pick({name: 'moe', age: 50, userid: 'moe1'}, function(value, key, object) { > return _.isNumber(value); > }); > ``` > => `{age: 50}` I'd be more enthusiastic about `Object.pick` or similar, accepting an iterable of whitelisted keys or a

Re: Question ... perhaps a proposal: extract from object to object

t distinction. -- T.J. Crowder *Farsight Software Ltd | 20-22 Wenlock Road, London N1 7GU | Company #8393428 tj.crow...@farsightsoftware.com | Direct: +44 (0)20 3627 4231 | Mobile: +44 (0)7717 842 414* If you've received this message in error, please let us know by forwarding it to i...@farsig

Re: Field initializers

ou can set accessible properties in an initializer after the call to the constructor: ```c# var obj = new Example() { x = 1, y = 2}; Console.WriteLine(obj.x); // 1 Console.WriteLine(obj.x); // 2 ``` -- T.J. Crowder On Sat, Mar 18, 2017 at 6:04 PM, Jordan Harband wrote: > I'd think

Re: Standardizing conditional try/catch

stack (I'm looking at you, IE11). -- T.J. Crowder On Sat, Mar 18, 2017 at 6:06 PM, Jordan Harband wrote: > If the condition can be just "any javascript", wouldn't that potentially > impede optimizations? Hopefully implementors can weigh in here, since > non-implemento

Re: Proposal: Boolean.parseBoolean

Any reason for not just using `Boolean.parse`? (Rather than repeating `Boolean` in the function name?) -- T.J. Crowder On Mon, Mar 20, 2017 at 6:54 PM, Dmitry Soshnikov < dmitry.soshni...@gmail.com> wrote: > On Thu, Mar 16, 2017 at 1:55 PM, Dmitry Soshnikov < > dmitry.sosh

Re: Proposal: Boolean.parseBoolean

Funny, I'd go the other way. We have `parseInt` in part because we also have `parseFloat`. `Date` has `parse` (but it doesn't return a `Date`, sigh). `JSON` has `parse`. For me, consistency with Java isn't important for this. My $0.02 for what it's worth... -- T.J. Crowd

  1   2   3   4   5   >