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