Hi,
I had a more detailed look at json-io and read the code a bit.
First, this does not seem to be too popular in the Java world, there is no
formal spec, I don't see or hear about much uptake. So from that perspective,
why follow it ?
Second, although at a first look their extensions seem reasonable, most are
quite Java specific, some inefficient.
The contents of @class is pure Java, it can even include their ugly primitive
array syntax (like '[B') if I understood it well. How can that be universally
mapped to another, different language ?
Their handling of primitive/non-primitive types (the endless int/Integer, ...
mess) makes the code quite complicated and some of that will probably come
through. We don't have those artificial differences.
Their custom handling of some special classes (Date, Timestamp, Timezone,
Class, ..) is understandable but again Java specific and not formally written
in a spec.
There seems to be @items and @keys fields that look suspicious.
Any non-Java language will have trouble being 100% compatible with that design.
It is probably not impossible to do, but why would you want to do that ? You
will always be a second rank citizen.
The handling of references using @id and @ref requires that the writer makes
two passes over the object graph (because it has to know up front which objects
will be used as reference targets). That is inefficient.
Like I said, STON does all of the above, but a bit better, IMHO, but I am
biased of course. FUEL, although different by being binary, handles the same
and more edge cases. When you want to magically serialise *any* object, you
always hit (language) implementation details, which are not good for cross
language portability.
IMO, json-io was *not* written with the goal of being cross-platform (meaning
cross-language).
There is a reason why JSON is what it is, limitations and all. It is quite
restricted, but it gives you portability.
All that being said, you could perfectly use Neo-JSON as a building block to
work with the json-io format, by going through a Maps/Lists (Dictionary/Array)
intermediate representation. It is a bit less efficient, but I will work.
Point>>#asJsonIo
^ { #'@class'->'java.awt.Point'. #x->x. #y->y } asDictionary
Point class>>#fromJsonIo: map
^ self x: (map at: #x) y: (map at: #y)
You will have to maintain a Point to 'java.awt.Point' mapping. And you will
have to walk the object graph to handles references.
But it will take time to get feature equality and a functioning implementation.
Sven
> On 12 Feb 2015, at 11:01, S Krish <[email protected]> wrote:
>
>
>
> https://github.com/jdereg/json-io
>
> I like the additional features of json-io : @ref / @id pair
>
> If we can have an JSONExtension which plays well with json-io, we have a
> simple way to interact with Java/Scala/Groovy JVM world for default.
>
> Present these as literals: String, Numbers, Date, Time, Literal Arrays ,
> booleans
>
> Rest all are type based marshalling/ unmarshalling
>
> "@type": "fully.qualified.name.toClass" for Pharo we can ignore the package
> name.. which can be the Category specifier for serialization purposes.
>
>
>
>
> On Thu, Feb 12, 2015 at 3:05 PM, S Krish <[email protected]>
> wrote:
>
> Even for GSON:
>
> http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.html
>
> {
>
> "type": "Circle",
> "properties": {
>
> though I prefer json-io: @type to make it unambigous for any case with
> instance variable named type and does not add another node to the tree..
>
>
>
> On Thu, Feb 12, 2015 at 2:58 PM, S Krish <[email protected]>
> wrote:
>
> 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
> >
> >
>
>
>
>
>
