You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 20, 2019. It is now read-only.
When serializing an array (likely, any collection) to JSON, each element of resulting JSON array contains the (potentially lengthy - long package name!) "tpe" entry. This is redundant, since the array itself already has a tpe entry with full information on element type. If a long array is serialized, current behavior would result in a file which is a lot larger than it has to be
val um = CommitUrlEmail("a","b")
val um2 = CommitUrlEmail("a2","b2")
val umList= Array(um,um2)
val pklumList = umList.pickle
println(pklumList.value)
[ "tpe": "scala.Array[long.loog.long.long.pkg.name.CommitUrlEmail]",
"elems": [
{
"tpe": "long.loog.long.long.pkg.name.CommitUrlEmail",
"commitUrl": "a",
"email": "b"
},
{
"tpe": "long.loog.long.long.pkg.name.CommitUrlEmail",
"commitUrl": "a2",
"email": "b2"
}
]
I would think that the specific type information would only be needed on collections whose types have variance. Otherwise it seems that on invariant types the extra tpe's aren't needed. Just brainstorming though.
over in https://github.com/sbt/serialization we have a pickle format for JSON that's a little more economical, though it does still write out the type for this case I believe. Conceptually if you never pickle/unpickle Any (meaning you only use StaticOnly mode) no type tags are needed at all for leaf types in the type hierarchy.
Good point, but 99% of the time a data structure will be homogeneous, or will contain 2-3 subclasses, so maybe specifying tpe1 tpe2 and tpe3 on array level, and referring to them on each element will work? Especially if it is a sealed hierarchy and all subclasses are known upfront...
Activity
adamdecaf commentedon Feb 7, 2015
I would think that the specific type information would only be needed on collections whose types have variance. Otherwise it seems that on invariant types the extra
tpe
's aren't needed. Just brainstorming though.havocp commentedon Feb 7, 2015
over in https://github.com/sbt/serialization we have a pickle format for JSON that's a little more economical, though it does still write out the type for this case I believe. Conceptually if you never pickle/unpickle Any (meaning you only use StaticOnly mode) no type tags are needed at all for leaf types in the type hierarchy.
eed3si9n commentedon Feb 8, 2015
Here's the case where having type info would help.
Unfortunately, Pickling 0.10.0 won't be able to unpickle that to
Array[Fruit]
but that's another story.julianrz commentedon Feb 8, 2015
Good point, but 99% of the time a data structure will be homogeneous, or will contain 2-3 subclasses, so maybe specifying tpe1 tpe2 and tpe3 on array level, and referring to them on each element will work? Especially if it is a sealed hierarchy and all subclasses are known upfront...