These are chat archives for mdedetrich/scala-json-ast
@Ichoran Regarding your comment earlier
That's some pretty wide fanout. In principle if encoding and decoding in memory is a likely scenario, this is the way to do it, but I'm skeptical that this is an important use case.
Can you explain this differently?
LinkedHashMap-based implementation, and when you modify them it switches to
Indeed I know what Circe does, which is precisely the point, its hiding the internal value of JSON object (and this is also according to @travisbrown and Circe’s design goals where users shouldn’t deal with the AST at all).
This is different to scalajson designs goals, at least with Circe if you want to work with the JSON object you have to call
.toMap on the object, which is different to ScalaJSON where the map of the object itself is directly exposed as a value
ScalaJSON where the map of the object itself is directly exposed as a value
can't we fake this by defining
Vector"fast enough" (meaning "not actually fast enough for any single-element stuff that you do seriously"), I'm skeptical that an eagerly-constructed VectorMap could be fast enough to satisfy everyone.
Doublein a JSON number, in memory, and then pulling it right back out again is a major use-case, so it doesn't really matter much what you do.
JNumber.apply(..)via flag to some degree was a feature creep in other words. and my inheritance was a reaction/refactoring to that.
Double -> AST -> Doubleperf is not super useful, then neither flag nor
JDoubleis all that useful
JsonDoubleconstructor in circe 0.9.0 (because it complicates things in some upcoming refactoring and as you say double-to-ast-to-double isn't a use case I care about).