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