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.<div><br>On Wednesday, 28 October 2015, Tab Atkins Jr. <<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones <<a href="javascript:;" onclick="_e(event, 'cvml', 'alex@weej.com')">alex@weej.com</a>> wrote:<br>
> I agree this is pretty important. Using actual maps really frees up a lot of<br>
> complexity, but the syntax is cumbersome to say the least.<br>
><br>
> Whatever the decided syntax, bare words as string keys is a really bad idea<br>
> IMO. The key syntax should be parsed as an expression, like the values are,<br>
> and like they are in basically every other language.<br>
><br>
> Another outstanding issue is that we might want the syntax for<br>
> `Immutable.Map`, or `WeakMap`, or `MapTwoPointOh` that improves deficiency<br>
> $x, $y and $z. I'd say introducing a special syntax for `Map` right now is<br>
> not ideal.<br>
<br>
Currently, the "extensible literal syntax" for this isn't that bad:<br>
<br>
const bar = 43;<br>
const map = Immutable.Map([["foo", 42], [bar, 44]]);<br>
<br>
It's a little more verbose because the entries have to be surrounded<br>
by [], but hey.<br>
<br>
~TJ<br>
</blockquote></div>