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]>: > 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]> 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]> 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] >> 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] https://mail.mozilla.org/listinfo/es-discuss
