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 [email protected] 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 <[email protected]> wrote: > > > On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <[email protected]> > wrote: >> >> >> >> > Le 17 déc. 2017 à 22:03, J Decker <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
