Yes, you are right, there is a problem for an object definition. Can't think of any good idea how to overcome this scenario :(
2017-09-12 21:48 GMT+03:00 Jeremy Martin <[email protected]>: > Apologies, I was butchering the property getter syntax. With the correct > syntax, the backwards compatibility concern remains, however: > > const get = "foo"; > > const obj = { > get > y() { return 2 } > }; > > console.log(obj.get); > // current: `undefined` > // under this proposal: `"foo"` > > You can try it yourself here: https://es6console.com/j7hy49k4/ > > > > On Tue, Sep 12, 2017 at 2:36 PM, Алексей <[email protected]> wrote: > >> Am... no. Right now this example would just not work. For now this code >> is invalid. >> >> 2017-09-12 21:33 GMT+03:00 Jeremy Martin <[email protected]>: >> >>> *> The reason why we have a discussions about whether to rely on ASI or >>> insert them manually is because ASI has problems (return is one of them). * >>> >>> This seems to come from the perspective that ASI was a poorly specified >>> feature, as opposed to a recovery mechanism for poorly terminated >>> statements. >>> >>> That being said, even with ASI completely removed from the discussion, >>> your proposal has some significant barriers to overcome -- most notably the >>> lack of backwards compatibility. >>> >>> Examples have already been provided where your proposal would change the >>> semantics of *already *valid code. E.g., >>> >>> const get = "foo"; >>> >>> const obj = { >>> get >>> y: 2 >>> }; >>> >>> console.log(obj.get); >>> // under current rules: `undefined` >>> // under your new proposal: `"foo"` >>> >>> If you introduce new rules to resolve that ambiguity or to preserve >>> backwards compatibility, you've now created a situation similar to ASI, >>> where developers have to remember a list of exceptions before they elide a >>> comma. >>> >>> Even in the absence of backwards compatibility concerns, you need to >>> provide a persuasive argument that the cost-benefit ratio justifies the >>> effort, and judging from initial feedback, I think that will be an uphill >>> battle. >>> >>> On Tue, Sep 12, 2017 at 2:12 PM, Алексей <[email protected]> wrote: >>> >>>> The reason why we have a discussions about whether to rely on ASI or >>>> insert them manually is because ASI has problems (return is one of them). >>>> And they can't be fixed because fixes are not backward compatible. Based on >>>> this experience it would be possible to determine the rules that would not >>>> have that gaps or their kind. >>>> >>>> 2017-09-12 20:32 GMT+03:00 Claude Pache <[email protected]>: >>>> >>>>> >>>>> > Le 12 sept. 2017 à 18:57, Алексей <[email protected]> a écrit : >>>>> > >>>>> > Don't you think that line break is a strong punctuation by itself? >>>>> >>>>> It could have been. Unfortunately, in JS, it is not. >>>>> >>>>> Automatic semi-colon insertion (ASI) could be seen as an attempt to >>>>> have their cake and eat it too. Or, as a compromise between the two >>>>> options >>>>> by making *some* line breaks significant (e.g., the one after `return`). >>>>> >>>>> But in general, line breaks are not significant enough to allow to >>>>> introduce ASI-like rules after the fact, that would work reliably enough. >>>>> >>>>> BTW, the title of the thread, “Make comma at the end of line >>>>> optional”, reveals a probable misunderstanding of the feature. In JS, >>>>> semicolons are not “optional”, they are “automatically inserted”. That >>>>> makes a difference when parsing: >>>>> >>>>> ```js >>>>> a = b >>>>> +c >>>>> ``` >>>>> >>>>> >>>>> —Claude >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> >>> -- >>> Jeremy Martin >>> 661.312.3853 <(661)%20312-3853> >>> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j> >>> >>> >> > > > -- > Jeremy Martin > 661.312.3853 <(661)%20312-3853> > @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
