Alexander Jones wrote:
Ok, thanks for clarifying. Not only does it preserve order but it also
permits non-string keys. You're still missing one detail which is that
`bar` would actually be a variable not a string key.
Another example to clarify that the key part would be an expression:
```
Map#{foo(42) + 7: "bar"}
```
I prefer this over the precedent set by object literals which would
require that [] are used around a key expression ("computed key") simply
I, on the other hand, think it should match object literals completely.
So your example would be
```
Map#{[foo(42)+7]: "bar"}
```
Yes, it's just for consistency and less WTF moment while learning the
details.
OTOH, there could be consistent contraproposal of:
```
Object#{foo(42) + 7: "bar"}
null#{foo(42) + 7: "bar"}
#{foo(42) + 7: "bar"}
```
where the first is equivalent to {[foo(42)+7]: "bar"}, the second is
pure container (Object.create(null)) filled with properties, and the
third is the default case, but I don't know which of the previous two -
the first is probably less confusing, though the feels more clean.
due to relieving the syntax noise, which is what this idea is all about.
Also, this is how it works in Python and I make no apologies about the
similarities ;)
Alex
On Wednesday, 28 October 2015, Viktor Kronvall
<viktor.kronv...@gmail.com <mailto:viktor.kronv...@gmail.com>> wrote:
Hello Alexander,
I see now that I misread your desugaring.
I read:
```
Map#{1: 6, bar: 'Hello', 2: 8};
```
as being desugared to:
```
Map[Symbol.literalOf]({1: 6, bar: 'Hello', 2: 8}[Symbol.iterator]());
```
But your proposal clearly states that is should be:
```
Map[Symbol.literalOf]([[1, 6], ['bar', 'Hello'],
[2,8]][Symbol.iterator]());
```
Which would preserve lexical ordering of entries. The fault is
completely mine. Sorry.
I like this proposal as it is extensible and not that noisy in
syntax. Using the `#` for this doesn't
seem like a bad idea either. People coming from Erlang will be
familiar with this as well.
2015-10-28 10:53 GMT+01:00 Alexander Jones <a...@weej.com
<javascript:_e(%7B%7D,'cvml','a...@weej.com');>>:
Hi Victor
Not sure I understand - the desugaring I wrote would absolutely
preserve the written ordering because it speaks in terms of an
ArrayIterator of key-value pairs. If the map type to which it's
applied chooses to forget the ordering then that's fine.
Alex
On Wednesday, 28 October 2015, Viktor Kronvall
<viktor.kronv...@gmail.com
<javascript:_e(%7B%7D,'cvml','viktor.kronv...@gmail.com');>> wrote:
> ```
> const map = IMap#{"foo": 42, bar: 44};
> ```
> It could desugar as, for the sake of example:
>
> ```
> Foo#{key: value, ...}
> ➔
> Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]())
> ```
I like this proposal. However, Maps should guarantee
insertion order when traversing the keys and values and
desugaring it like that does not respect this guarantee or
more precisely it will lead to (in my opinion) unexpected
order of the keys.
```
Object.keys({1: 6, bar: 'Hello', 2: 8}); // → [ '1', '2',
'bar' ]
```
If I'm not mistaken this will be same order for `{1: 6, bar:
'Hello', 2: 8}[Symbol.iterator]()`.
This implies that:
```
Map#{1: 6, bar: 'Hello', 2: 8};
```
Will not have entries in the order `[[1, 6], ['bar',
'Hello'], [2,8]]` but instead `[[1,6], [2,8], ['bar','Hello']]`.
This means that possible future destructuring of a Map will
be harder to reason about.
2015-10-28 2:21 GMT+01:00 Alexander Jones <a...@weej.com>:
True, but easy to mess up and only be treated to a
runtime error. Three nested brackets at the start and
end could definitely be better, and this just encourages
people to use POJSOs instead. Also not a very uniform
interface if you look at how to construct a Map, Set or
Immutable.List at present, though admittedly constructor
call for the ES6 types would be a partial improvement.
On Wednesday, 28 October 2015, Tab Atkins Jr.
<jackalm...@gmail.com> wrote:
On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones
<a...@weej.com> wrote:
> I agree this is pretty important. Using actual
maps really frees up a lot of
> complexity, but the syntax is cumbersome to say
the least.
>
> Whatever the decided syntax, bare words as string
keys is a really bad idea
> IMO. The key syntax should be parsed as an
expression, like the values are,
> and like they are in basically every other language.
>
> Another outstanding issue is that we might want
the syntax for
> `Immutable.Map`, or `WeakMap`, or `MapTwoPointOh`
that improves deficiency
> $x, $y and $z. I'd say introducing a special
syntax for `Map` right now is
> not ideal.
Currently, the "extensible literal syntax" for this
isn't that bad:
const bar = 43;
const map = Immutable.Map([["foo", 42], [bar, 44]]);
It's a little more verbose because the entries have
to be surrounded
by [], but hey.
~TJ
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
