Yup, although there are a lot of examples of these use cases existing in other standard libraries. i.e. you can argue that dealing with Byte[Array] or Byte[Char] isn't something that people should typically deal with, this functionality still exists in the stdlib of almost every major language (and this isn't the stdlib, this is just the scala platform).
I personally think there is benefit in having the unsafe as part of this package, libraries such as SBT have demonstrated there is use for this
I am not against using a special number type (such as Circe's
BiggerDecimal) however I wanted to keep the implementation as lean and as trivial as possible, and use a validated String. Maintaining a custom number implementation isn't something thats easy (for similar reasons this is also why there is a separate implementation called
unsafe which handles multiple values per key + ordering for JsonObj, I don't want to maintain a new custom datastructure that handles all of the corner cases of JSON object).
Also note that the AST is meant to be abstract by other libraries themselves, so some library using spire (for example) would use their own real type rather than a
BiggerDecimal (for example). I would be more open to using a custom number type if it was part of stdlib, but unfortunately
BigDecimal has known issues and I don't think that maintaining a custom number implementation completely adhers to the goals of the AST (although I am open to change my mind on this).
Regarding the number converters, I am actually on the fence for their design myself. I have asked numerous times for feedback on the converters and your actually the first person to address this directly. The main emphasis of the current design of the number converters is for easy extensibility (i.e. for other custom number types).
Also regarding the note about throwing exceptions, I think that this is more of a style matter. Converting to a specific number type should not fail at all (at least for the standard
ast) considering that all numbers are validated by a regex. You may lose precision when converting to something like a
Double, but I believe this is something to be expected since we are dealing with numbers in the first place.
Agreed, but one step at a time. JSON parsers are a lot harder than just the AST's, and they tend to have tradeoffs that are far less negligable than the AST itself. Its going to be easier to write a parser once we have settled on the AST.
If possible, sure. The separations that now exist are mainly for
js.Array instead of
Array. This is deliberate both due to performance and also so it doesn't pull in scala's stdlib). There is also custom implementations of stuff like equals and hashcode for the different platforms, and also performance/platform related functions (i.e.
toJsAny isn't something that makes sense on the JVM).
I don't think this is a big concern, the implementation of the scala json AST is trivial (and this shouldn't really change) and the differences are there for quality of life reasons