Re: Default values for nulls

What about allowing any expression then? x || 4 x/4 x + 4 x + w //maybe allow only "previous" parameter values as scope x + a //SyntaxError: 'a' undefined in parameters scope On Tue, 13 Oct 2020 at 14:39, Michael Luder-Rosefield < rosyatran...@gmail.com> wrote: > I know I am not the only one

Re: Proposal: Forced Chaining Operator "!."

Can someone confirm if the following nullish coalescing assignment operator proposal example would work for this, or would it produce some other kind of result?: ```js (((table ??= {}).user ??= {}).id ??= {}).type = 'int' ``` Regardless, I'm not a TC39 member but I would definitely be against

Re: Conditional assign operator

Yes I like syntactic sugar when it doesn't sacrifice clarity (e.g. class, arrow functions). However, I do like the logical assignment operator pointed out by Jordan somewhat more than the "conditional assign" ("if not assigned") idea at the beginning of this thread. My reason is that you cannot

Re: syntax for case ranges

2020 at 7:58 AM kdex wrote: > >> Yes, there have been numerous backwards-incompatible changes to the >> language >> over the years. >> >> You can find a list of them in section E of the ECMAScript language >> standard. >> IIRC, that list is non-exhausti

Re: syntax for case ranges

table? Dunno. > > —Claude > > Le 3 févr. 2020 à 15:23, Naveen Chawla a écrit : > > Hi! > > I didn't understand your reply. > > I think currently it would raise an error, because 1 < 2 < 3 is currently > saying (probably) true < 3. > > But a "ne

Re: syntax for case ranges

aScript (just curious)? I've probably missed your point entirely, because I saw a short message "3 < 2 < 1 //true", and I've assumed you meant it in reverse. On Sat, 1 Feb 2020 at 23:12, Mark S. Miller wrote: > 3 < 2 < 1; // true > > > On Sat, Feb 1, 2020

Re: syntax for case ranges

Certain languages allow the expression 0 wrote: > Still better to discuss it there - it's highly related to your suggestion. > And I'm pretty sure an issue already exists related to that. > > On Fri, Jan 31, 2020 at 09:06 Sultan wrote: > >> The pattern matching proposal does not handles the

Re: Re: Proposal: `await.all {...}` for parallelism

ive bracket (maybe `async [ await|| foo ]`) would > be too different from everything else in the language and might read > as an array, which discourages using non-expression statements inside > it > > > > On Wed, Nov 27, 2019 at 9:57 AM Naveen Chawla > wrote: > >

Re: Re: Proposal: `await.all {...}` for parallelism

> > The way things are shaping up, it's starting to look like an ad-hoc > version of this proposal of mine: > https://github.com/isiahmeadows/non-linear-proposal > > As I stated earlier, I feel it's premature, especially before we figure > out how observables fit into it all. > &g

Re: Re: Proposal: `await.all {...}` for parallelism

If I have, as per your examples, x1 = await||actionAsync1() x2 = await||actionAsync2(x1) //x1 is undefined here, only resolved on the next "non-parallel-await" vs adding a line between the two calls: x1 = await||actionAsync1() let c; x2 = await||actionAsync2(x1) ...does the `let c`

Re: Re: Proposal: `await.all {...}` for parallelism

OK I'm even more confused now. x1 is surely not a resolved value until all the next "non parallel await" so is it "undefined" until then? Could you give an example of what you mean by the `await.all { ... }` block syntax bringing "complexity on returning values assignment, specially when" "about

Re: Re: Proposal: `await.all {...}` for parallelism

Hi Manuel, I think your idea is too much magic, in the sense of not being straightforward to understand. It actually executes subsequent code first, e.g. async { x1 = await || doStuffAsync1(); x2 = await doStuffAsync2(); x3 = await || doStuffAsync3(); } In your idea, `doStuffAsync3()`

Re: Re: Proposal: `await.all {...}` for parallelism

wrote: >>> >>>> Hey, you're absolutely right! It's OK because it just means things are >>>> more deterministic before the block exits. It doesn't impact any reasonable >>>> expectations *during* the block. >>>> >>>> I am convi

Re: Re: Proposal: `await.all {...}` for parallelism

preceded by "await" with a check for whether it returns > a thenable and add it to an array if it does. But with the concurrency > feature it would also have to defer executing the code at all until the > right time as otherwise we're still starting zillions of "processes" at >

Re: Re: Proposal: `await.all {...}` for parallelism

However, if `await.all { ... }` were to mean "wait for all non-awaited async function calls made within this block to complete before proceeding", as I suggested earlier, I think that could satisfy determinism for "await" wherever it is used, and satisfy the original motivation: ``` await.all {

Re: Proposal: `await.all {...}` for parallelism

poorly-reasoned-about > code, I'm open to iterating on it to find a syntax that works with the > developer to handle parallelism in a safe way, and also doesn't > require them to write too much boilerplate code. > > On Thu, Nov 21, 2019 at 3:16 PM Naveen Chawla > wrote: > >

Re: Proposal: `await.all {...}` for parallelism

Yes of course, I was responding to your proposal and the subsequent email about it being incompatible with existing JavaScript because "await" on its own accepts non-promises, so wouldn't return an array of results from an array of promises, hence why I proposed await.all etc. On Thu, 21 Nov 2019

Re: Proposal: `await.all {...}` for parallelism

I have a solution for that: const promises = [...] await.all promises //returns an array of results await.race promises //returns a single result etc. On Thu, 21 Nov 2019 at 09:51, manuelbarzi wrote: > AFAIK `await` can only accept an `expression` as a `Promise`, not other > thing: >

Re: Proposal: `await.all {...}` for parallelism

I don't like the idea of await behaving differently inside vs outside of the "await.all" block, and I think is a source of bugs: await.all { const x = await doSomethingAsync(); //x is still undefined here! Not the case outside of an await.all block } Maybe if you drop the "await" in your

Re: function invocation with just commas for explicit undefined optional arguments in the middle

>> Simply eliding a parameter seems like a nice example of terse/expressive >> syntax. /2-cents >> >> >> On Wed, Oct 30, 2019 at 4:21 PM Cyril Auburtin >> wrote: >> >>> I proposed it a long time ago >>> https://esdiscuss.org/topic/ignoring-arg

Re: function invocation with just commas for explicit undefined optional arguments in the middle

I tend to agree and one thing I like in good code is "glanceability" - the ability to "glance" and see what's going on. If I have doStuff(bar,, foo,, far) vs doStuff(bar, foo,, far) they don't look too different, but really they are. I normally break params into separate lines so I wouldn't

Re: Optional chaining syntax but with the "mice" operator ?

tial side-effects is more bug prone than the > proposed mouse trap, as it's subtle, yet "promoted" by the `?.` + `??` > pattern. > > On Mon, Sep 9, 2019 at 11:16 AM Naveen Chawla > wrote: > >> "resultsContainerOrSingleResult" appears to be the end variable. I ju

Re: Optional chaining syntax but with the "mice" operator ?

(void after first >> `.trap` access + self clean on next microtask), so manye we'll come back to >> this discussion once we all understand the use case and why it's actually >> very useful in some circumstance. >> >> Regards >> >> >> &g

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

eness we want. > > The only place unbounded concurrency really tends to make sense is when > you don't have a giant array of things to process - you have a handful of > predetermined tasks that you know can run concurrently. I can picture a > language feature for that, but it wouldn't i

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

In my mind there is a cognitive load cost in adding language constructs (unless they significantly otherwise reduce cognitive load). In this case, I find omitting the "await" would suffice for a lot of people, and for those who want the loop to conceptually "hang" until all are completed (which I

Re: Optional chaining syntax but with the "mice" operator ?

There has to be a better pattern than returning the "foo()" if the baz property doesn't exist. I'm curious what you would want to do with the resulting "foo()" anyway. I can imagine a flow where I want "bar", and it doesn't exist it doesn't. I cannot imagine wanting the "foo()" in place of it.

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

Can someone tell me exactly how just omitting "await" doesn't broadly achieve the "concurrency" objective? On Fri, 6 Sep 2019, 20:04 Cyril Auburtin, wrote: > It could be probably added as a `Promise.all(iterable, concurrency?)` > > Some existing implementations: > -

Re: Optional chaining syntax but with the "mice" operator ?

Typically, "dot" expressions navigate through values of different types, making "type branching" the inevitable next step in those cases (unless you introduce a common method for further processing for each of those types). So I'm not sure how ultimately that would be avoided. On Fri, 6 Sep 2019

Re: Optional chaining syntax but with the "mice" operator ?

ntually provide > feedbacks of what went wrong: > > ```js > const name = await some.query(id) if (typeof name !== 'string') > throw name; > ``` > > As summary, considering how semantic it's the operator in both visual and > practical meanings, and considering it's not possible

Re: Optional chaining syntax but with the "mice" operator ?

I think introducing this operator encourages bad logic design like "instanceof", isArray etc. These are unreadable disambiguation factors in that they don't inform about which part the expression is going to the next stage in the process. Also it leads to "type branching", which tends towards more

Re: Array.prototype.joinWith(iterable)

ng new to add, nothing different to expect. >>>>>> >>>>>> The template literal as is returns a string, but if you use tags, as >>>>>> functions, you deal with an array and a collection or extra values (0 to >>>>>> template.length - 1). >>>>>&g

Re: Array.prototype.joinWith(iterable)

; The current way to flatten a template via tag, used already in various >>>> projects for a reason or another, is the following one: >>>> >>>> ```js >>>> function tag2str(template) { >>>> let str = template[0]; >>>> for (let i =

Re: Proposal: Range Expression

I like it. I might prefer it in square brackets e.g. [ x ... y ] ? On Sun, 18 Aug 2019 at 23:24, Artem Kobzar wrote: > ### Proposal: Range Expression > > The proposal based on one of the worst things in JavaScript Arrays. > > If i as developer want to make sequence of some numbers or characters

Re: Array.prototype.joinWith(iterable)

t;> projects for a reason or another, is the following one: >>> >>> ```js >>> function tag2str(template) { >>> let str = template[0]; >>> for (let i = 1, t = template.length; i < t; i++) >>> str += arguments[i] + template[i]; >>>

Re: Array.prototype.joinWith(iterable)

; would produce "a0b1c0d" so that > there's never an `undefined > > > > > > > > > > On Fri, Aug 16, 2019 at 12:01 PM Naveen Chawla > wrote: > >> I'm just not seeing what it's supposed to do. If you could give a brief >> explanation o

Re: Array.prototype.joinWith(iterable)

I'm just not seeing what it's supposed to do. If you could give a brief explanation of the array method, and the string method then of course I would get it. I know it would seem obvious to you from the examples alone, it's just not to me. On Fri, 16 Aug 2019 at 08:32, Andrea Giammarchi wrote:

Re: Array.prototype.joinWith(iterable)

"weave"? (I've likely missed the purpose of the method) On Thu, 15 Aug 2019, 18:12 Andrea Giammarchi, wrote: > That;s not useful for template literals tags though > > _.zip(['a', 'b', 'c'], [1, 2]); > [["a", 1], ["b", 2], ["c", undefined]] > > it basically does nothing I've proposed ... any

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

Can anyone tell me what's wrong with a really simple approach? Wherever you are calling method(), just call methodWithAfter(): //in base class methodWithAfter(){ method(); after() } What am I missing, guys? On Fri, 19 Jul 2019 at 07:43, Michael Haufe wrote: > Revisiting this topic:

Re: A way to fire logic at the end of completion of the current class method (regardless of super call order).

hAfter() { > > method2() > > } > > } > > > > > > Additionally, requiring me to call ` super.methodWithAfter()` is an > Anti-Pattern: https://en.wikipedia.org/wiki/Call_super > > > > /Michael > > > > *From:* Naveen Chawla &g

Re: Re: Proposal: Selector/Select Expression

The problem is the same unless you have a way of "gluing" an expression as a "shorthand-function" e.g. `:.prop1 / :.prop2` won't be interpreted as a single function that performs x.prop1 / x.prop2, but rather an attempt to perform division with 2 functions On Wed, 26 Jun 2019 at 10:44, Michael

Re: Proposal: Selector/Select Expression

I am guessing this doesn't allow any operations other than the "dot path" to a function or property... Are you comfortable with that? If so, why? I have found myself doing things like a=>a.x/2 . I couldn't do that in proposed way, could I? Have you found, in your experience, that a "dot path only"

Re: Proposal: Static Typing

Yes the real value of strict types, in my view, is at development time, not at run time. However I would be curious to know if anybody has a usage for them at run time, and an example of such a case... Otherwise, yes a "toolchain" that allows strict typing using JavaScript without having to "use

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

If only some of my proposals that were actually useful got this much attention On Mon, 11 Mar 2019, 4:33 pm Jeremy Martin, wrote: > With respect, it's still not clear how you want to interact with the array > of values once you've destructured a Float into your array format. > > If all you have

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

I've probably missed it, but what application are you building that would use this feature? Or, under what circumstances would an application use this feature? On Fri, 8 Mar 2019 at 17:24 guest271314 wrote: > The code for "transforming" numeric values to array and array to numeric > value has

Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

What is the real world use case, presuming it's not just an academic exercise On Thu, 7 Mar 2019, 9:08 pm guest271314, wrote: > Ability to adjust *nth* digit of an integer or decimal by adjusting > decimal or integer at *nth* index of array, to try to solve OEIS A217626 > oeis.org/A217626

Re: Proposal: Duration

I don't like it. Duration is just milliseconds for me. On Mon, 4 Mar 2019 at 18:47 Alexandre Morgaut wrote: > Here a proposal to make ECMAScript natively support a Duration Object > > I talked about it a long time ago (2011) on the WHATWG mailing list in the > context of the Timers API: >

Re: Proposal: switch expressions

hecks, but those don't > *need* to be inherited to work.) > > - > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > On Thu, Feb 28, 2019 at 12:40 PM Naveen Chawla > wrote: > > > > I'm not sure that pattern matching handles deep levels

Re: Proposal: switch expressions

r > this anyways - it covers more use cases and is all around more > flexible, so I get more bang for the buck. > > - > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > On Thu, Feb 28, 2019 at 9:23 AM Naveen Chawla > wrote: > > > >

Re: Proposal: switch expressions

[Animal.CAT]: > houseAnimal, [Animal.LION]: wildCatFood, [Animal.TIGER]: > wildCatFood, [Animal.CHEETA]: wildCatFood,}const food = > cases[animal] ? cases[animal]() : (() => {throw new Error("Unsuppored > Animal")})(); > > ``` > &g

Re: Proposal: switch expressions

Isn't the best existing pattern an object literal? const cases = { foo: ()=>1, bar: ()=>3, baz: ()=>6 } , x = cases[v] ? cases[v]() : 99 ; What does any proposal have that is better than this? With

Re: Deep spread operator (Bilal Abdullah)

Correction, suppose const b = { a : b } . Circular references can be cloned trivially, as far as I can tell On Tue, 23 Oct 2018 at 20:52 Naveen Chawla wrote: > Is there any real problem with circular reference cloning? I don't see > any, Please let me know in the simplest ca

Re: Deep spread operator (Bilal Abdullah)

Is there any real problem with circular reference cloning? I don't see any, Please let me know in the simplest case e.g. { a: a } (obviously contrived syntax here) Otherwise, I agree completely about the 4 dots being the wrong syntax for this, precisely for the reason you gave On Tue, 23 Oct

Re: [nodejs] Re: javascript vision thing

ES6 doesn't encourage any design patterns. All it does is allow you to shorten existing constructs into simpler-to-program ones, and simpler-to-understand ones. I want TC39 to continue in this vein, making big things easier to accomplish with less, hence, speeding up development time (very

Re: proposal: String.prototype.padCenter

t. BTW, > I do not know why we did not implementing this function when the padStart e > padEnd was developed too. > > And again, I think it's not hard to be done, but necessary. And Claude > Pache, thanks for your exemple. > > Naveen Chawla, yes this is the idea, as the same as the other

Re: proposal: String.prototype.padCenter

How would you combine padStart and padEnd to get the desired result? Just curious, because the idea would be to create a minimum of 32 chars with the original string centered inside the "padding" (if there is any) On Wed, 22 Aug 2018 at 07:26 Isiah Meadows wrote: > What's wrong with combining

Re: Small Proposal "!in"

I still prefer truthy checks when logically valid. Otherwise a truthy check + [any other validity check in the logic]. I find `in` far too quirky and I'd rather never ever use it. I think `instanceof` is also a messy pattern. I've always preferred having an overridden method on the object that

Re: [proposal] Persistent variables in functions/methods

Seems attractive at first, but the problem for me is readability. It seems to me that we are trained to understand variable assignments as happening where they are written, e.g. ```js persist let counter = 0; counter++; ``` With the "persist" feature, the value of counter after `counter++`

Re: Small Proposal "!in"

ul 9, 2018 at 9:08 PM, Naveen Chawla > wrote: > >> I don't use `in`. >> >> What do I get with `'x' !in obj` or `!(x in obj)` that I don't get with >> !obj['x'] ? >> >> Genuinely asking - I don't know what I am missing. >> >> I use obj[x] because I

Re: Small Proposal "!in"

I don't use `in`. What do I get with `'x' !in obj` or `!(x in obj)` that I don't get with !obj['x'] ? Genuinely asking - I don't know what I am missing. I use obj[x] because I believe it's a more familiar syntax and I believe I get the same outcome..(?).. On Mon, 9 Jul 2018 at 22:41 Steve Fink

Re: Re: Proposal: Array.prototype.shuffle (Fisher-Yates)

I don't think there's such a thing as "real random" in digital algos, just "pseudo random". Apart from card games, what's the use case? (I'm not in TC39 so I can't vote on this) I think that this comes after `toObject(keyCallback)`, `takeWhile`, `skipWhile`, and `forEachReturningOriginalArray`

Re: Proposal: Allow Promise callbacks to be removed

leads* to better predictability On Tue, 24 Apr 2018, 4:44 pm Naveen Chawla, <naveen.c...@gmail.com> wrote: > Having promises be non-breakable I think is an advantage. I think it least > to better predictability without having to check if another part of the > code may have "b

Re: Proposal: Allow Promise callbacks to be removed

Having promises be non-breakable I think is an advantage. I think it least to better predictability without having to check if another part of the code may have "broken" it. So I tend to prefer callbacks explicitly handling expiry in application logic, rather than allowing promises to be

Re: Proposal: Allow Promise callbacks to be removed

How can you terminate an async call? All you're doing is refusing to handle the result. Explain how I'm wrong if so. On Tue, 24 Apr 2018 at 13:27 Andrea Giammarchi wrote: > The `isStillValid` is limited in possibilities. I think listeners open > new possibilities,

Re: Proposal: allow primitives to be explicitly returned from constructors

What's the use case? Maybe there's a nice way of doing what you want On Fri, 20 Apr 2018 at 19:17 T.J. Crowder wrote: > On Fri, Apr 20, 2018 at 2:23 PM, Oriol _ > wrote: > > No, `typeof` is not reliable, because it's

Re: EcmaScript Proposal - Promised functions

I'd prefer a "new Promise" literal analogous to {} for objects and '' for strings: ```js p\ resolve=> setTimeout( resolve, forHowLong) \ ``` I think the "this.resolve" proposal wouldn't work for methods, for example. On Thu, 12 Apr 2018 at 23:25 Michał Wadas

Re: Proposal: Static sort method on Array

`slice()` is better than `Array.from()` if you already have an array because you can chain it with the other Array.prototype methods. Good point about not needing it after you've done a map/filter/concat or whatever, since you already have a new array. However I agree with the thrust of a

Re: What do you call a `function` function?

"function" function is the best out of all of the alternatives you mentioned. "Anonymous function declared with the function keyword" if it's not too wordy. On Sat, 7 Apr 2018 at 23:50 Eli Perelman wrote: > I've always referenced them as: > > Function declarations: > >

Re: Proposal: if variable initialization

> > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > > On Mon, Mar 26, 2018 at 2:33 AM, Naveen Chawla <naveen.c...@gmail.com> > wrote: > > I don't get it. Please give an example of the per-iteration &g

Re: Proposal: if variable initialization

I don't get it. Please give an example of the per-iteration initialization in the while loop... (the for-loop version before `;` does it before iteration, not per-iteration) On Mon, 26 Mar 2018 at 07:20 Isiah Meadows wrote: > As a counterpoint, Rust and Swift are the

Re: Proposal: if variable initialization

www.isiahmeadows.com > > > On Sun, Mar 25, 2018 at 12:55 AM, Naveen Chawla <naveen.c...@gmail.com> > wrote: > > I understand the fear about "bad code" potentially sprouting from it. I > > guess I'm not as bothered as long as I can do what I want. So it's a &

Re: Proposal: if variable initialization

, historically, other languages such as Perl allowed `if( > >> (my $x = 1) > 0)` and `foo( my $x = 100)` and became the ugly child of > >> power programming; whereas Golang, born much later, has limited > >> initializations to things such as `if( x:=1; x > 0)` and has kept

Re: Proposal: if variable initialization

realworld example, hard to find variable declaration: > > $redis->subscribe( 'queue', my $callback = sub { > ... > }); > ``` > > > On Fri, Mar 23, 2018 at 7:21 AM, Naveen Chawla <naveen.c...@gmail.com> > wrote: > > I'm still not seeing a compelling case

Re: Proposal: if variable initialization

I'm still not seeing a compelling case for not allowing `const` / `let` declarations to be evaluated as expressions. Or I've missed it. As was noted, `if(x = 5)` is already allowed. Is `if(const x = 5)` really that much of a stretch? To answer a concern about a function call like

Re: Add "???" Unimplemented

Can you give a simple example? On Wed, 21 Mar 2018 at 00:44 dante federici wrote: > With the advent of TypeScript, classes, etc one feature I liked from scala > is: `???`, the [Predef.???]( > https://www.scala-lang.org/api/current/scala/NotImplementedError.html) >

Re: Proposal: if variable initialization

at 12:20 Naveen Chawla <naveen.c...@gmail.com> wrote: > What would `if.value` look like in an example? > > Wouldn't it be possible to have something like `if(const x = getX() && > const y = getY())` to capture more than just the conditional if required? > I'm guess

Re: Proposal: if variable initialization

What would `if.value` look like in an example? Wouldn't it be possible to have something like `if(const x = getX() && const y = getY())` to capture more than just the conditional if required? I'm guessing that would probably break something somewhere, but I'm not sure what. On Wed, 21 Mar 2018

Re: Expanding Object Shorthand

Yes it seems like a natural combination of the destructuring and object shorthand features (the `=` version that is). Can anybody name the pitfalls or point to where they have been mentioned (if any have been)? On Sun, 18 Mar 2018 at 08:52 Michael Theriot wrote: >

Re: Re: Explainer/Spec: Smart pipelines

If generator composition isn't directly supported somehow, then I'd have to say I personally find the function composition proposal more compelling on its own, even in the absence of a pipeline operator. On Mon, 12 Mar 2018 at 05:56 Tab Atkins Jr. wrote: > On Sun, Mar 11,

Re: Explainer/Spec: Smart pipelines

Can you explain how it solves the generator / async generator aspect of the proposal here: https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition I can't seem to find an example in the explainer. Maybe you can formulate a way of doing it, then add it in the

Re: Function composition vs pipeline

on > > Sounds like the combination of pipeline + partial application would result > in what is essentially the same as function composition operator: > > ``` > const h = ? |> f |> g; > ``` > > Which results in `h` being the composition `g • f`. > > > On Feb 2

Re: Function composition vs pipeline

t; leads to much more expressivity than if you have > to call the pipeline (and collapse) where it is defined. > 2018年2月24日(土) 14:32 Naveen Chawla <naveen.c...@gmail.com>: > >> The function composition operator composes function pipelines into >> functions for later

Re: Function composition vs pipeline

the function pipeline immediately, so it is really only a different way of calling functions. On Fri, 23 Feb 2018 at 12:37 Jordan Harband <ljh...@gmail.com> wrote: > How is either operator not "a different way of calling functions"? > > On Thu, Feb 22, 2018 at 8:34 PM

Function composition vs pipeline

I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features: e.g. https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition https://github.com/tc39/proposal-pipeline-operator They can

Re: Re: Async Class

I think `awaitNew MyObject()` would fit the thrust of your idea more. This would allow `new MyObject()` to still be an instance of the object instead of a promise, even if the constructor is async. It would dispatch the async parts of the constructor to the background instead of awaiting it. e.g.:

Re: Re: Async Class

In the example, promise rejection can be handled with a try+catch inside `initializeAsync()` itself. But we're deviating from the topic of "async constructor", from which this is separate On Sun, 18 Feb 2018, 2:37 pm Naveen Chawla, <naveen.c...@gmail.com> wrote: > There is no

Re: Re: Async Class

There is no rule that says you must propagate every promise. `initializeAsync` doesn't return anything, so the constructor just kicks off the async process. On Sun, 18 Feb 2018, 2:02 pm T.J. Crowder, <tj.crow...@farsightsoftware.com> wrote: > On Sun, Feb 18, 2018 at 8:27 AM, Nave

Re: Proposal: Object.path([ ... ], defaultValue)

Of course you can compose paths with it (and even without it), but it doesn't compose on it's own like a standard path syntax could. On Sun, 18 Feb 2018, 9:14 am Jordan Harband, wrote: > Seems like it composes fine (using `??.`/`??[` syntax): `function > retrieve(obj, path) {

Re: Re: Async Class

Like this: ```js class MyObject{ constructor(){ initializeAsync(); } async initializeAsync(){ await doSomething(); await doSomethingElse(); //etc. } } ``` Of course if you wanted to await at the constructor call level (and await inside the

Re: Re: Async Class

You can just call an async method from the constructor (without await) - and then let that async method handle all the asynchronicity. Does this satisfy your use case? I think `async constructor` would make more sense than `async class`. Calling `new MyObjectAsync()` would have to return a

Re: Suggestion: Destructuring object initializer.

A big thing in a programming language for me is "glanceability" (ability to glance at code and discern roughly what's going on). Allowing destructuring braces to be mixed in object literals may well be a natural extension of destructuring: I'm not denying that. I just think that since they

Re: Suggestion: Destructuring object initializer.

of syntax. Not impossible, just a potential source of bugs and/or delay in understanding the data structure being declared. On Sat, 10 Feb 2018 at 10:01 Naveen Chawla <naveen.c...@gmail.com> wrote: > I'm not a TC39 member, but I have a little readability issue with > destructuring insi

Re: Suggestion: Destructuring object initializer.

I'm not a TC39 member, but I have a little readability issue with destructuring inside an object: ```js { {p1, p2} = p, {q1, q2} = q } ``` has a very different meaning than ```js { p: {p1, p2}, {q1, q2} = q } ``` On Fri, 9 Feb 2018 at 16:55 Bob Myers wrote: > Thanks for your

Re: Suggestion: a chainable in-place alternative of `Array.prototype.map`.

Already discussed (at the end there's an Array.prototype.each idea that's the same): https://esdiscuss.org/topic/return-value-of-foreach On Thu, 8 Feb 2018 at 14:17 Yeong-u Kim wrote: > # Suggestion: a chainable in-place alternative of `Array.prototype.map`. > > > >

Re: Suggestion: Infix operators/functions

I don't like the idea of custom operators only because of readability of code - it can be different for different pieces of code, and so I think it is a larger surface area for bugs, so I think it would be a net negative. However, I do like the idea of allowing e.g. `+` to be used intuitively and

Re: Do-Expressions Proposal Stalled?

page don't succeed, for me, in establishing how (if at all) using a do-expression could (vs the most elegant alternative currently). On Thu, 18 Jan 2018 at 17:16 T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > On Thu, Jan 18, 2018 at 11:39 AM, Naveen Chawla <naveen.c

Re: Do-Expressions Proposal Stalled?

; wrote: > On Thu, Jan 18, 2018 at 9:51 AM, Naveen Chawla <naveen.c...@gmail.com> > wrote: > > const x = (tmp=>tmp*tmp+1)(f()); > > Sure, that's another way an arrow function (with its attendant overhead) > could be used for that specific example. Harder to read than

Re: Do-Expressions Proposal Stalled?

lly with good indentation: question1 ? answer1 : question2 ? answer2 : answer3 On Thu, 18 Jan 2018 at 14:25 T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > On Thu, Jan 18, 2018 at 8:23 AM, Naveen Chawla <naveen.c...@gmail.com> > wrote: > > &g

Re: Do-Expressions Proposal Stalled?

8 at 13:53 Naveen Chawla <naveen.c...@gmail.com> wrote: > Also, I don't find it very readable/clear when reading it in code. Maybe > I'm missing the whole point, but the comma operator forces you to wrap each > non-expression language construct (e.g. for loops) into a function, whi

Re: Do-Expressions Proposal Stalled?

be happier if it wasn't introduced. On Thu, 18 Jan 2018 at 13:29 Naveen Chawla <naveen.c...@gmail.com> wrote: > I'm not necessarily in favour of the proposal. I think the comma operator > feature in current javascript already covers at least some of the use cases. > > On Thu, 18 Jan 20

Re: Do-Expressions Proposal Stalled?

I'm not necessarily in favour of the proposal. I think the comma operator feature in current javascript already covers at least some of the use cases. On Thu, 18 Jan 2018 at 01:58 Peter Jaszkowiak wrote: > https://github.com/tc39/proposal-do-expressions > > It appears that

  1   2   3   >