Yojson 2.0.0 plans

If anything, it’s ezjsonm that should use yojson types, isn’t it? Yojson is much, much more widely used.

3 Likes

I have to agree with @c-cube here, I think it would have much less of an impact on the opam universe if ezjsonm were to align than the other way around. Otherwise I’m totally in favor of unifying the types indeed!

I suppose you are talking about this (yojson) and this (ezjsonm).

The problem is that the Yojson representation is an interpretation of what JSON is, not a representation. There are no integers in JSON, only floats. And if you are going to operate on geometrical data like geojson you can’t believe how annoying these Ints and Floats are going to be (not even talking about conversion costs).

I think it would make sense to make Basic.t a representation of JSON whereas Safe.t could be a convenient (for those for whom integers are convenient) interpretation of it. There could even be conversion functions between those.

Though I would suggest we concentrate on releasing 2.0.0 with the current (mostly minor and hopefully not affecting too many people) breaking changes and then rethink the Basic/Safe/Raw variants for 3.0.0 (along with some maintainability updates).

1 Like

Though I would suggest we concentrate on releasing 2.0.0 with the current (mostly minor and hopefully not affecting too many people) breaking changes and then rethink the Basic/Safe/Raw variants for 3.0.0 (along with some maintainability updates).

Why not bite the pill and do the breaking changes now, though? :slight_smile:

It’s easier to migrate only twice, I think. Besides, I imagine that a
lot of people use Safe.t or use Basic.t through code-generators and
ppxes?

While I see the appeal of doing a big-bang release instead of a constant stream of breakage I can see the ideas in the RFCs at least somewhat controversial.

The current master does exactly what the current release can do, just the types are different, so for users it it is at worst a simple search & replace. But removing `Tuple would make functionality that people use just go away completely with no trivial way to upgrade. So I would like to make sure that this is a change that we can do safely without splitting the ecosystem into old-Yojson and new-Yojson or delaying the release forever to find just the perfect set of changes.

1 Like

ezjsonm will not change, due to the reasons that @dbuenzli outlined. The ejzsonm value types are the simplest types that represent a parsed version of the underlying jsonm representation. This approach means that you can easily drop down to an incremental parse with jsonm if you can’t store the full value in memory with ezjsonm.

However, I’d be happy to merge in conversion functions from Yojson into Ezjsonm if appropriate, since they are just polymorphic variants (so no dependency is needed from ezjsonm to yojson directly).

1 Like