Allow any quoted string to be multiline?
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.)
me at isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
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>
>> > 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss