Unable to create objectN because Field.encode is not exported

[Minnozz]

The docs say:

The codecs are currently available for N from 1 to 15. If you have an object with more fields, make a custom codec. It might be a sane idea to steal object15 implementation and routinely extend it to the number of fields required.

However, it seems like it is not possible to implement object16 and further myself because Field.encode is not exported.

[nkrkv]

Oops, indeed. Thank you. I’m thinking about a way to implement object16 and further easier without exposing internals. If nothing helps, I’ll expose module Field stuff. Meantime you can try to steal the whole module Field as well 🙄

[nkrkv]

Can’t find an elegant idea to suggest how a user can make an arbitrary objectN. They are all ugly. And asking to extend object15 is inhumane too.

I’ve done a simple code generator that can generate object23 or, say, object123. Now I’m thinking about what maximum N would be OK to include in Jzon. In any case, starting from some N the user destruct/construct functions are going to look insane (123 args, anyone?). Chances are high, in the case of such wide JSON objects, there’re some patterns in the shape which are better served by a specialized custom codec made just for this particular case… So I’m thinking about N=25 or so.

@Minnozz, out of curiosity, what JSON do you have so that object15 is not enough? Will object16..object25 resolve your issue? Or maybe you’re asking about further Ns just for some experiment?

[Minnozz]

Thanks for looking into this!

I have a data structure that would need object17, so including up to 25 seems very reasonable. You're right that writing the constructor/deconstructor is a lot of typing and an alternative would be preferable.

Does Jzon currently have an easy way to write a custom codec for such a large object?

[nkrkv]

Does Jzon currently have an easy way to write a custom codec for such a large object?

I have no idea how to do this, keep 100% type safety, and avoid boilerplate at the same time. Waiting for an “aha-moment” :) If only ReScript had named tuples like in Python... destructors and constructors might be trivial identity functions.

[nkrkv]

Just released Jzon 1.3.0 with object1...object25. Closing this for now. If you come up with an idea of better coding wide objects, it would be nice to hear.