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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
