When I look at `Map#{"foo": 42}` I don't see much difference with `new
Map([['foo', 42]])`.
Since you can pass expressions there, it's already possible to do it with
current syntax. There is only a bunch of extra brackets(`[` and `]`) that I
don't like.
On Wed, Oct 28, 2015 at 5:51 AM Alexander Jones <a...@weej.com> wrote:
> Ah, there is actually a good case for keeping barewords in object literals
> but removing them from map literals, and that's due to objects accessing
> string properties as bare words, too. This is almost never the case for
> other map types.
>
> ```
> const o = {foo: 42};
> o.foo === 42;
> o.bar = 43;
>
> const m = Map#{"foo": 42};
> m.get("foo") === 42;
> m.set("bar", 43);
> ```
>
> Would you agree?
>
>
> On Wednesday, 28 October 2015, Alexander Jones <a...@weej.com> wrote:
>
>> Hi Herby
>>
>> Agree with your concerns about symmetry with object literals, but many of
>> the uses of maps benefit from having non string keys, and in such case
>> generally everything would involve wrapping in []. Trying to use an Array
>> as a key would be quite ugly with the extra squares required
>>
>> ```
>> const precachedResults = MyMap#{[[1, 2, 3]]: [1, 4, 9]}
>> vs
>> const precachedResults = MyMap#{[1, 2, 3]: [1, 4, 9]}
>> ```
>>
>> Perhaps a middle ground could be that if you want to use an expression
>> that would otherwise be a bare word, you enclose in parens. The visual
>> binding of the colon is deceptive anyway, so I tend to do this if the key
>> expression contains a space:
>>
>> ```
>> MyMap#{1 + 2 + 3: 6}
>> vs.
>> MyMap#{(1 + 2 + 3): 6}
>> ```
>>
>> But I think I still prefer that the parsing for the key part is just
>> standard expression evaluation, personally, and the POJSO literal barewords
>> remain the only special case.
>>
>> Indeed,
>>
>> ```
>> Object#{1: "one", Symbol(): "sym"}
>> ```
>>
>> Could Object-key-ify the keys, i.e. turn them into strings if not
>> symbols, and Just Work (but a default implementation on the Object
>> prototype is questionable!). That said I'm not sure we should be using
>> Object for this kind of thing. At this point I don't know what a raw
>> `#{}` should produce... There may be a better use case for it in the
>> future, horrible ASI complexities notwithstanding.
>>
>> Alex
>>
>>
>> On Wednesday, 28 October 2015, Herby Vojčík <he...@mailbox.sk> wrote:
>>
>>>
>>>
>>> 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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
