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 <[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
>>> >
>>> >
>>>
>>>
>>>
>>
>

Reply via email to