I think you're overlooking the parse-time shape checking, Isiah, which in the new world order of type inference and checking seems like a necessity to me.
While I fully appreciate that Tab's solution involves the least number of specification additions, I still would rather write this without the extra pair of parens and the `new` which was omitted, just to cut down on the noise and really reduce the number of reasons people have to use `Object` instead of a more suitable type. Consider embedding lists as keys in a map which compares keys by value: ``` let m = new Dict(#(1: "one", new List(#(1, 2)): "array of 1 and 2", null: "the null value")); ``` I think this just starts to look quite gnarly, and the fewer occurrences of `new` I see in declarative code the better. Re-consider my offered alternative, (putting `#{}` and `#[]` back on the table to visually distinguish abstract list and abstract mapping): ``` let m = Dict#{1: "one", List#[1, 2]: "array of 1 and 2", null: "the null value"}; let platonics = Set#["tetrahedron", "cube", "octahedron", "dodecahedron", "icosahedron"]; ``` I think it would also make sense to allow `...` to include the results of iteration over some other iterable. ``` let nums = [2, 3, 4]; let setOfNums = Set#[1, 2, 3, ...nums, ...range(20, 50)]; ``` Cheers On Sunday, 29 November 2015, Isiah Meadows <isiahmead...@gmail.com> wrote: > With that syntax, I'm not even sure it's necessary. It's not much more > concise than a list of 2-tuples. Don't quite see the benefit the other than > a few characters. > > On Sat, Nov 28, 2015, 22:22 Tab Atkins Jr. <jackalm...@gmail.com> wrote: > >> On Thu, Oct 29, 2015 at 6:23 PM, Alexander Jones <a...@weej.com> wrote: >> > I don't think borrowing object notation is a good idea. What exactly >> does >> > >> > ``` >> > const myMap = Map#{ >> > get foo() { return 100; }, >> > set foo(v) {} >> > constructor() {} >> > }; >> > ``` >> > >> > mean? >> > >> > Honestly, a very significant portion of the use cases I have for *actual >> > maps* don't involve string keys. So to borrow object notation and have >> to >> > constantly write keys in [] is pretty naff: >> > >> > ``` >> > const describe = Dict#{ >> > [1]: "one", >> > [[1, 2]]: "array of 1 and 2", >> > [null]: "the null value", >> > }; // please no! >> > ``` >> > >> > If it makes people feel too weird to have comma separated, colon split >> > key-value pairs within curlies that *don't* parse like POJSOs, we could >> have >> > completely non-ambiguous parse with normal parentheses, I think? >> > >> > ``` >> > const describe = Dict#( >> > 1: "one", >> > [1, 2]: "array of 1 and 2", >> > null: "the null value", >> > ); >> > ``` >> > >> > That might limit confusion while giving a syntactically clean way to >> define >> > maps. Let's consider that a future mapping type like Dict compares >> > non-primitive keys by abstract value instead of by reference identity. >> There >> > are *tonnes* of nice use cases that open up that are taken for granted >> in >> > other languages and other classes like Immutable.Map - we're not there >> yet >> > with ES6 built-ins, so perhaps people might not yet appreciate the >> value of >> > this. >> > >> > To reiterate a previous point, object property access with a statically >> > defined string key is idiomatically written `obj.foo`, so it makes >> sense for >> > symmetry to have `foo` appear as a bareword in a literal defining `obj = >> > {foo: 42}`. For most mapping-type classes this symmetry simply does not >> > apply, and frankly neither should it. >> > >> > Also, I specifically suggested that the consumed value is an >> ArrayIterator >> > rather than an Array, because I feel having an intermediate Array >> around is >> > placing too high an importance on the humble Array. If the >> implementation >> > really wants an Array to work on internally, they can simply call >> > `Array.from` with little cost. But if they want an Immutable.List they >> can >> > have that instead without ever seeing an actual Array. (The >> Symbol.fromHash >> > method is just Symbol.literalOf as I called it - same thing, modulo >> > bikeshed.) >> >> I strongly agree with a lot of the points here, and think they suggest >> the OP's suggestion was generalized in slightly the wrong way. >> Producing a Map literal is indeed too specific to justify syntax, but >> what's suggested is not a special way of calling some constructors, >> but *a literal syntax for 2-value iterators*. >> >> We have a literal syntax for 1-value iterators: just use an Array. >> It's lightweight (2 chars + 1 char per item), and typos in the syntax >> are caught at compile time. Our existing literal syntax for 2-value >> iterators (an array of length-2 arrays) fails at both of these: it's >> heavyweight (4 chars + 4 chars per item), and typos in the syntax are >> only caught at runtime, when it's actually iterated over. >> >> Having a lightweight, compile-time-checked 2-value iterator literal >> that desugars to an N×2 Array (or ArrayIterator) fixes all these >> problems, and makes it easy to write Map literals, Immutable.Dict >> literals, or anything else. Using the hash-paren syntax suggested >> above: >> >> ``` >> let m = Map(#(1: "one", [1, 2]: "array of 1 and 2", null: "the null >> value")); >> ``` >> >> There's no need to invent a new function-calling syntax or add a new >> well-known symbol to anything. It Just Works™ as long as the function >> you pass it to expects a 2-value iterator. >> >> (From other languages, there doesn't appear to be any call for N×3 >> literals or anything higher >> >> ~TJ >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss