Also I would like to reiterate that errors in the shape of the N-by-2 array are only caught at runtime. That's really not ideal.
On Wednesday, 28 October 2015, Dave Porter <[email protected]> wrote: > I don’t love any of the specific suggestions so far, but saving 3 + 2n > keystrokes isn't the point – readability and learnability are. Visually, > `new Map([[‘foo’, 42]])` is a mess. > > On Oct 28, 2015, at 9:28 AM, Michał Wadas <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > Difference between any proposed here syntax and current state ( new Map([ > [1,2], [2,3] ]); ) is.. > > 3 characters + 2 characters/entry. > > > > > 2015-10-28 17:22 GMT+01:00 Mohsen Azimi <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>: > >> 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 <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected]> 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 >>>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>>: >>>>>> >>>>>> 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 >>>>>> <[email protected] >>>>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> >>>>>> 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 <[email protected] >>>>>> >: >>>>>> >>>>>> 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. >>>>>> <[email protected]> wrote: >>>>>> >>>>>> On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones >>>>>> <[email protected]> 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 >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://mail.mozilla.org/listinfo/es-discuss >> >> > _______________________________________________ > es-discuss mailing list > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
