Just some thinking out loud:

I know that the documentation suggests that Standards.JSON.decode may possibly return an object, but based on my (possibly faulty) recollection, I don’t think there’s any code that actually does that… we’d probably need something like decode(string json, int flags, program decode_into) or something similar, if you already knew what the datatype was supposed to be. Otherwise, you’d need a variant that consulted the “program selection” mechanism.

In a fantasy world that doesn’t currently exist, we could have a default object decode implementation that simply calls setters in an empty (i.e. void create()’ed) object, with adjustments to the field mapping made via annotations. Absent that (or perhaps overridden by,) decode_json(mapping data) on an empty object is probably the easiest approach. It seems inefficient, but I think you’d have to decode the object in order to pass something to the “program selector” in order to determine what class to decode into. I think there’s something to be said for not having to write a decode_json method for every datatype you want to be able to decode… providing `->identifier() or set_identifier() for each field seems like a good practice anyway.

Bill

On Jan 8, 2019, at 12:41 PM, Mateusz Krawczuk <krawczukmat@gmail.com> wrote:

I've been suggested by the QuickType team to create a pull request of what I've already got, and here it is: https://github.com/quicktype/quicktype/pull/1149
You're all more than welcome to leave any feedback in GitHub's review tool, especially regarding my encode_json() implementation for generated Pike classes. 
If you would like to try it out, simple clone my fork and follow the instructions in README.

It even has enum and union support!

Regarding JSON decoding - we can obviously use Standards.JSON.decode() that accepts a string and returns a Pike object whose type depends on the input value, but a greater challenge is determining what type is represented by the JSON (that "program type_for_json(mapping some_decoded_json);" mentioned by Bill). I would really appreciate some tips, ideas and suggestions on it.

Unfortunately, inheritance is not yet supported by QuickType. That's a great shame, because it's a key feature we need if we want to make use of the LSP and DAP specification schemas. Fortunately, I've received some guidelines from the QuickType team on how it might possibly be implemented, and I'll get to it after I finish Pike support.

I have to say that the QuickType team is very eager to help and really friendly, so if I really encourage to join me in this project if anyone's interested.

Matt

śr., 2 sty 2019 o 23:49 H. William Welliver III <william@welliver.org> napisał(a):

I was thinking about enums and I'm not sure that Pike enums are "featureful" enough for use in this: I think there is an assumption that you be able to get the value of an enum type from a string representation of its value. For example:

enum foo { bar, gazonk }

foo x = gazonk;

So given the string "gazonk" in the context of foo, return the value that's contained in x in the example above.


I guess there also needs to be a convention for decoding a set of json data for an object type (i.e, each type includes a function that is /sort/ of the opposite of encode_json()). I also imagine that there would need to be a type - selector registry object that keeps track of all of the types it knows how to decode and the means for determining what type a json blob represents:

program type_for_json(mapping some_decoded_json);

Bill

January 2, 2019 12:04 PM, "Mateusz Krawczuk" <krawczukmat@gmail.com> wrote:
Inspired by the debugger discussion, I've started implementing QuickType support for the Pike language. You can check it out by cloning my github fork[1], checking out to 'Pike' branch, and following the 'Contribute' section in README.md. After successful installation, you can run $ ./script/quicktype --lang pike test/inputs/json/samples/pokedex.json to see if it's working fine.

The main motivation for this is generate Pike classes for the JSON-RPC messages specified in Microsoft's Debugger Adapter Protocol and Language Server Protocol. I imagine this could also turn out handy for people working with JSON-based APIs.

There is plenty of work to be done here, like supporting enums and handling reserved statements, so I encourage you to contribute!
Any feeback is more than appreciated.
Mateusz