Allow any quoted string to be multiline?

Isiah Meadows isiahmeadows at gmail.com
Mon Dec 18 10:37:15 UTC 2017


I'll note that making such an adjustment to JSON itself would
interfere with many newline-delimited JSON stream parsers,
particularly those who look for the newline before parsing the segment
itself. (Most JS-based parsers do that, since it's easier and faster
to pass a slice to `JSON.parse` than it is to parse it incrementally.)

-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Mon, Dec 18, 2017 at 4:47 AM, 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
>


More information about the es-discuss mailing list