On 2023-11-11, at 1:51 PM, christoph.thiede@student.hpi.uni-potsdam.de wrote:
One can certainly make arguments about how the next loop around will raise an error because there be no appropriate value in the next char to be read. Is that the 'proper' thing?
I think so ... 'truefalse' parseAsJson fails because end of input is expected, '[truefalse]' fails because $] or $, or whitespace is expected, etc. Yes. Handling all of this within the parser/parser part for boolean, in this example, sounds less coherent to me.
I suggest that it is a matter of expectations; for me it seems more appropriate that you get the error reported in the context of 'truefalse is a bad token' rather than 'whoops, no proper character found, look here it's $f instead of whitespace' - but as I said, ask someone with a CS degree!
So if you don't have any other reason, could we just forward WebUtils class>>#jsonDecode: to Json class>>readFrom:?
I *think* that we want the check at the end of the parsing to detect some error cases.
More importantly, this is also a matter of compatibility: For example, in the past, parsing JSONL (https://jsonlines.org/) was as easy as
jsonl := '{"name": "tim"} {"name": "christoph"}' readStream.
jsons := Array streamContents: [:out | [jsonl skipSeparators; atEnd] whileFalse: [out nextPut: (WebUtils jsonDecode: jsonl)]].
This doesn't work any longer because now #jsonDecode: complains that the stream is not fully consumed. So, my position remains. :-)
Never heard of jsonl before. Quite why anyone would not just wrap things in [] to make it a json array I don't know.
The reason it used to work is that the code in WebUtils was fairly aggressively making sure that 'true' worked and 'truef' didn't. You definitely need to talk with Levent about this aspect of the code!
Regarding -0.0e0: Do these classAndValueEquals assertions even make sense? Where did you find this requirement? Python and Ruby answer a float in this case as well. JavaScript doesn't but in JavaScript 0.0 and 0 have the same class. If not required, I would opt to remove this assertion.
They were all like that previously.
Regarding the Unicode test (WebClientServerTest>>#testStrings), should WebUtils class>>jsonEncode: really escape non-ascii/latin1/? characters? ... For the Json package itself I think like Levente that it should not, but is there any reason nowadays not to send arbitrary characters over the network? The main issue is that there is no sender of #jsonEncode: or #jsonDecode: in the image, so we don't know whether senders will handle the text encoding themselves. Maybe we should deprecate both selectors now completely to overcome these questions? After all, JSON is no longer a responsibility of WebClient.
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-11-10T13:47:19-08:00, tim@rowledge.org wrote:
On 2023-11-10, at 11:55 AM, <christoph.thiede(a)student.hpi.uni-potsdam.de> <christoph.thiede(a)student.hpi.uni-potsdam.de> wrote:
Speaking from my personal impression: the job of #readFrom: in Squeak is to take one object, as Levente said, from the stream, but not to exhaust the stream. The idea behind this is that parsers can contain other nested parsers. A nice example of this can be found in the TextAttribute hierarchy:
I'm very happy to leave issues of "what a parser should do" in the hands of people with CS degrees.
The small argument I can summon here is that the EBNF diagram appears to me to require that 'true' is followed by defined whitespace (which as I mentioned seems to include nothing, which seems very odd to me) or a separator or a terminator such as end of dictionary } and so forth. To my mind 'truefalse' breaks that requirement. One can certainly make arguments about how the next loop around will raise an error because there be no appropriate value in the next char to be read. Is that the 'proper' thing? Dunno. Mostly what I care about is does it work in a way that makes some sense and produces useful results.
So if you don't have any other reason, could we just forward WebUtils class>>#jsonDecode: to Json class>>readFrom:?
I *think* that we want the check at the end of the parsing to detect some error cases.
Wide-characters/UTF-8: I agree with Levente here. Why would you want to make Json more heavyweight by also giving it a responsibility for encoding?
That was dropped, and FWIW I agree. I was initially simply trying pass the old tests to match the outgoing code.
Tests: The json tests in the WebClient are still failing, right? Also, is there any reason not to move them into Json package now?
The ones left are there as a reminder to whomsoever can summon up more enthusiasm and fix/solve them. I had to decide on a stop point and move on to some other issues.
tim
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim No one is listening until you make a mistake
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Hid behind the door when they passed out brains.