Extending NeoJSON
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
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 <krishnamachari.sudhakar@gmail.com> 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
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 <sven@stfx.eu> 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 <krishnamachari.sudhakar@gmail.com> 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
Even for GSON: http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.htm... { "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 <krishnamachari.sudhakar@gmail.com> 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 <sven@stfx.eu> 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 <krishnamachari.sudhakar@gmail.com> 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
https://github.com/jdereg/json-io <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 <krishnamachari.sudhakar@gmail.com> wrote:
Even for GSON:
http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.htm...
{ "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 < krishnamachari.sudhakar@gmail.com> 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 <sven@stfx.eu> 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 <krishnamachari.sudhakar@gmail.com> 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
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 <krishnamachari.sudhakar@gmail.com> 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 <krishnamachari.sudhakar@gmail.com> wrote:
Even for GSON:
http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.htm...
{
"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 <krishnamachari.sudhakar@gmail.com> 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 <sven@stfx.eu> 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 <krishnamachari.sudhakar@gmail.com> 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
You are right. Stick to pure json spec is best as NeoJSON / Gson does. Anything else should be application's headache, exactly as Gson advices, as much is yours. I was just not shaking of the XMLRPC / SOA approach out of my head. It is getting cleared now. !.. let me work through my use case and come back if I need to at all on this. On Fri, Feb 13, 2015 at 7:04 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
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 <krishnamachari.sudhakar@gmail.com> 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 < krishnamachari.sudhakar@gmail.com> wrote:
Even for GSON:
http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.htm...
{
"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 <
krishnamachari.sudhakar@gmail.com> 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 <sven@stfx.eu>
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 <krishnamachari.sudhakar@gmail.com> 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
participants (2)
-
S Krish -
Sven Van Caekenberghe