I get your point .. like GSON we should not type the json string output, if we want it to adhere abs to spec.
The saving grace for gson in Java is if you just give the root level object type, rest of it is automatic typing. We lack that capability in Pharo. Though there also for types specified as an interface can then require code assistance in deserializing. So either we follow a meta data route, code helper methods, that is needed for deserializing a JSON as spec or let it have an optional @type tag.. to make the whole thing automatic That way we can be both gson / or any other lib compatible for reading given format ignoring the extra tag, but helps if given to hydrate the object. On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe <[email protected]> wrote: > Hi, > > I will read a bit about json-io and come back to you. > > In any case, JSON is a standard that explicitly excludes typing info, and > yes I know it has been added in several places. NeoJSON's mission is to > stay true to the pure spec and to be efficient. Of course, it could be > extended or subclassed if its original goals remain in place. > > BTW, STON is what I think JSON with typing info should be ;-) > > Sven > > > On 12 Feb 2015, at 06:33, S Krish <[email protected]> > wrote: > > > > > > > > Can I extend NeoJSON to be more like json-io. > > > > * Object serialization > > * format synchronization > > > > To help make it bidirectional for Pharo to external world serialization > / deserialization > > > > > > Seems the closest to what is appropriate for Pharo - Scala/ Groovy / Java > > > > > > Gson : no type information.. > > Jackson: painful annotation or workarounds > > > > > > >
