Revival of JEP 198 (Light-Weight JSON API)?

[Laurence Cable]

On 4/23/20 3:41 PM, John Rose wrote:
> On Apr 23, 2020, at 11:05 AM, forax at univ-mlv.fr wrote:
>> most APIs do not provide a generic tree API but a data binding API that takes a tree of types (a bean/record/interface tree) and a stream of JSON tokens and construct the corresponding Java representation (creating instances Bean/Record/Proxy).
> Yep.  A Lisp refugee like me will immediately think “S-expressions
> are enough; why use anything else” and that me to look for some
> sort of clunky prefab node structure.  The more modern side of me
> will look for a mapping or transcoding to/from the event stream
> and whatever AST or other data I choose to work with at the moment.
>
> My point here is that the event stream “layer” of the library is
> a safe-ish first step, even if it fails to use value types in the clever
> way you suggest.  The next layer up will surely be data binding,
> and maybe a prefab tree for folks like me.  IMO, the upper layers
> will want to work well (IMO) with *both* mutable vs. immutable
> (easy to edit vs. safe) AST representations, just as ju.List supplies
> both options, and will also want to perform more ad hoc transcodings
> (not just standard ASTs) to both mutable and immutable objects.
> The immutable objects are likely to be inline objects, sometimes.
> (For that matter, inlines can also express logically mutable objects.)

> _/*The longer we delay nailing down the transcoding layer, the more 
> future features of the language we can use to make that layer more 
> flexible and powerful*/_.
+1!
>
> — John