Allow any quoted string to be multiline?

Alexander Jones alex at weej.com
Mon Dec 18 11:58:59 UTC 2017


Good point, but generally quoted keys like that are signs that you probably
really need a Map!

Aside, seems like it could be a fairly cheap spec change to allow template
literals for string property keys.

On Mon, 18 Dec 2017 at 11:20, Michael Rosefield <rosyatrandom at gmail.com>
wrote:

> There can absolutely be breaking changes from doing that. Take this, for
> example:
>
> const someObj = { 'some.key': 'some value' };
>
> That throws an error if using template literals, as you need to use
> computed property syntax (i.e., enclose the template literal in square
> brackets).
>
> [image: image.png]
>
>
> On Mon, 18 Dec 2017 at 10:09 Alexander Jones <alex at weej.com> wrote:
>
>> I question why 3 forms of quotation exist in modern codebases. Just use
>> template literals. The only reason not to is resistance to change. ESLint
>> will autofix for you.
>>
>> On 18 December 2017 at 09:47, J Decker <d3ck0r at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <claude.pache at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> > Le 17 déc. 2017 à 22:03, J Decker <d3ck0r at gmail.com> a écrit :
>>>> >
>>>> > I do see there are work-arounds (similar as using a hammer to put in
>>>> a screw)
>>>> >
>>>> > I don't see a reason for why not allow multiline strings for other
>>>> quote types.  I know... because people want more errors and to have their
>>>> hand held to identify missing close quotes?  much like the desire to add
>>>> types and type checking.
>>>>
>>>> Yes, you gave a valid reason just after having said you didn’t see a
>>>> reason: transforming bugs (missing quote) into early errors, so that it is
>>>> easier to debug...
>>>>
>>>> The obvious workaround, i.e. using a template literal without
>>>> placeholder, doesn’t seems too heavy-weight; on the contrary, it is
>>>> probably the lightest one can imagine.
>>>>
>>>>
>>> It's not actually :) lightest I can imagine is to allow single and
>>> double quoted strings to be multiline also.
>>> I was considering this because of an issue on my extended json parser.
>>> during development it simplified the code making a single path for
>>> gathering a string that only had to check for closing quote or backslash.
>>> having to test for 4 more characters was then 3x the work... so I just cut
>>> out the extra work, since it break anything.  The only thing left was ...
>>> that it didn't break anything if a newline was found.
>>>
>>> So I figured I'd mention the possibility here and see how much push back
>>> I got.  I don't actually think that 'protection from bad coding' is a very
>>> strong argument.  there's lots of single character omissions or insertions
>>> that can cause ghosted errors that aren't nearly so obvious.  Especially
>>> since syntax highlighting would show a overflowing string very quickly
>>> (more than missing a + in += or having a +  on an = that you didn't mean
>>> for instance).  It would be a change that would take some time to propagate
>>> to a lot of tools; but is a change that's entirely backward compatible and
>>> breaks nothing from the past.
>>>
>>>
>>>
>>>
>>>> —Claude
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171218/0042eb1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12726 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171218/0042eb1d/attachment-0001.png>


More information about the es-discuss mailing list