On Thu, Jan 18, 2018 at 11:25 AM, Peter Jaszkowiak wrote:
> Isn't there a proposal for `Map#setAll`? That would fulfill the other use
> case.
Or, stealing naming from Python, Map#update. (I've asked for this in
the past and would be very happy to see it.)
~TJ
___
Isn't there a proposal for `Map#setAll`? That would fulfill the other use
case.
On Jan 18, 2018 12:24, "Oriol _" wrote:
> > I believe there's a very simple way to do this today: new Map([...mapA,
> ...mapB, ...mapC]).
>
> But this only works if you want to create a new map, of course. Can't be
>
> I believe there's a very simple way to do this today: new Map([...mapA,
> ...mapB, ...mapC]).
But this only works if you want to create a new map, of course. Can't be used
to assign to an existing map.
- Oriol
___
es-discuss mailing list
es-discuss@
On Thu, Jan 18, 2018 at 6:59 PM, Gil Tayar wrote:
>
> I believe there's a very simple way to do this today:
> new Map([...mapA, ...mapB, ...mapC]).
facepalm
Yup: https://jsfiddle.net/m23Lgkr1/
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@moz
I believe there's a very simple way to do this today: new Map([...mapA,
...mapB, ...mapC]).
Almost as nice as map.assign :-)
- Gil Tayar
On Thu, Jan 18, 2018 at 8:12 PM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Thu, Jan 18, 2018 at 6:08 PM, Mike Samuel wrote:
> >
> > What if,
In the issues for the proposal people are discussing making most statements
capable of being used as expressions. Then the value of `do` is less
important, but still necessary for some things:
```
const thing = if (cond) { a; } else { b; };
```
Then you only need `do` to introduce a new block sco
On Thu, Jan 18, 2018 at 6:08 PM, Mike Samuel wrote:
>
> What if, instead of a variety of assign methods, we respeced
> Object.assign to do this given a Map as the left-value?
I think even if one posits that that would have been a good idea when
`Object.assign` was defined, the ship has sailed. Co
On Thu, Jan 18, 2018 at 12:37 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Thu, Jan 18, 2018 at 5:28 PM, 森建 wrote:
> >
> > This code is redundant. I just want to write
> > `mapA.assign(mapB, mapC);`.
>
> FWIW, it would be more in keeping with `Object.assign` if it were on `Map`
On Thu, Jan 18, 2018 at 5:28 PM, 森建 wrote:
>
> This code is redundant. I just want to write
> `mapA.assign(mapB, mapC);`.
FWIW, it would be more in keeping with `Object.assign` if it were on `Map`
rather than `Map.prototype`. E.g., you'd write the code above like this:
```js
Map.assign(mapA, map
Hi there,
I want to add `Map#assign` to TC39 Stage 1.
ECMAScript `Object` has `Object.assign`.
On the other hand `Map` doesn't have assigning method.
For example, we must write JavaScript like the following:
```js
const mapA = new Map([["foo", 1], ["bar", 2]]);
const mapB = new Map([["baz", 3]
On Thu, Jan 18, 2018 at 12:39 PM, Michael Rosefield
wrote:
>
> Perhaps we could use `do` in front of any statement to make it
> treatable as an expression; we could have pure `do`, `do while`
> (as distinguished from `do-while`...), `do switch`, `do for`
I believe the proposal does that (or w
Ha, yes, seems we're on the same page here. I agree that `do` is necessary
to distinguish between object literals (really makes you wish that standard
keyboards had access to more symbols so that we could avoid all this
overloading of meaning), but I'd love to know what the issues with using
these
On Thu, Jan 18, 2018 at 12:21 PM, Michael Rosefield
wrote:
>
> Just to stick my uninformed oar into this, I notice what
> `do-while` statements *already* return a value in the exact way
> as the proposal.
FYI, it's not just `do-while`: Any statement (including the block
statement) "returns" the v
Addendum: all non-function/class statement blocks seem to act like this,
```
for (x of ['val']) { x; }
// "val"
for (x in ['val']) { x; }
// "0"
let x = 1
// undefined
while (x) {
x-= 1;
x;
}
// 0
switch(1) {
case 0: 2;
case 1: 6;
}
// 6
```
This raises the general question: wh
Just to stick my uninformed oar into this, I notice what `do-while`
statements *already* return a value in the exact way as the proposal.
```
do {
if(true) 1;
else 2;
} while(false)
// 1
do {
if(!true) 1;
else 2;
} while(false)
// 2
```
Of course, since this is a statement rather than an expres
I agree it's a misuse, my point is simply why introduce the possibility?
Key question for me (for any feature): show how it can reduce the chances
of bugs.
Arrow functions succeed, for example: by removing nested "this" context,
thereby simplifying moving of code around etc.
Async await succeeds,
On Thu, Jan 18, 2018 at 11:39 AM, Naveen Chawla
wrote:
> ...but can you imagine a heavily nested conditional algorithm
> where it's not immediately clear you're inside a "do" expression?
I can. I would call it a misuse of the `do` operator, just like it is when
you do that with conditionals or ne
I find it easier to read. Less to read, same (or greater) level of clarity.
As for your question about the bug surface area:
```js
const
formattedInput =
do {
if(isValid(input)){
getFormattedValidInput(input);
postToServerAsync(inpu
On Thu, Jan 18, 2018 at 9:51 AM, Naveen Chawla
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 the `do` or
the more verbose arrow I posted, but sure.
-- T.J. Crowder
__
const x = (tmp=>tmp*tmp+1)(f());
I've not seen a use case for do-expressions that can't already be done more
elegantly. The proposal page certainly doesn't provide it, except for an
opinion about how nested ternaries are "awkward". I've never found nested
ternaries awkward, especially with good in
On Thu, Jan 18, 2018 at 8:23 AM, Naveen Chawla
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, which makes the e
First, that's something you could enforce in a linter. Second, just as
a heads up, `if`/`else` as an expression is actually pretty common -
consider Ruby as one example of this in a very procedural language.
-
Isiah Meadows
m...@isiahmeadows.com
Looking for web consulting? Or a new website?
S
Oh, and also, I don't like the idea of allowing if-elses to be turned into
expressions. That's what ternaries are for. Again, this harms readability
and is another surface area for the "accidental code after last executed
statement" bug I mentioned in my last post.
On Thu, 18 Jan 2018 at 13:53 Nav
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, which
makes the expression itself clearer (in my opinion) than a do-expression.
A
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 the do-expressions pro
25 matches
Mail list logo
