Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Enumeration Support for Jerkson #8

Open
gzoller opened this issue May 6, 2011 · 12 comments
Open

Enumeration Support for Jerkson #8

gzoller opened this issue May 6, 2011 · 12 comments

Comments

@gzoller
Copy link

gzoller commented May 6, 2011

It would be a great addition to Jerkson if it supported ser/deser of Scala Enumerations. Sample below:

object Day extends Enumeration {
val Mon, Tues, Wed, Thurs, Fri, Sat, Sun = Value
}

@Ashalynd
Copy link

+1

Also the following construct doesn't seem to work:

sealed abstract class Status
case object ON extends Status
case object OFF extends Status

if one tries to serialize/deserialize the object containing such type, it is serialized as {}

if we do something like:
case object ON extends Status
{val strValue:String="ON"}
case object OFF extends Status
{val strValue:String="OFF"}

then it does put these values in when serializing, but crashes and returns null when tries to deserialize.

@acruise
Copy link

acruise commented Dec 6, 2011

I would dearly love to be able to serdes arbitrary algebraic data types. I have a lot of pairs of Foo and FooDTO classes. :(

@fooblahblah
Copy link

+1

3 similar comments
@artgon
Copy link

artgon commented Jul 5, 2012

+1

@diegovar
Copy link

diegovar commented Aug 3, 2012

+1

@crumbpicker
Copy link

+1

@jdanbrown
Copy link
Contributor

I just tried hacking this, and I don't see any way to deserialize enumeration values:

scala> object Colors extends Enumeration { val Red, Blue, Green = Value }
defined module Colors

scala> Colors.Red
res61: Colors.Value = Red

scala> manifest[Colors.Value]
res62: Manifest[Colors.Value] = scala.Enumeration$Value

scala> manifest[Enumeration#Value]
res63: Manifest[Enumeration#Value] = scala.Enumeration#scala.Enumeration$Value

scala> manifest[Colors.Value] == manifest[Enumeration#Value]
res64: Boolean = true

Basically, if I say Json.parse[Colors.Value](string), then manifest[Colors.Value] doesn't appear to contain any more information identifying Colors or Colors.type than Enumeration#Value does (i.e. none), which I think is what we'd need to get at Colors.withName(string) to construct something like Colors.Red, Colors.Blue, etc.

@imikushin
Copy link
Contributor

salat has _typeHint field for exactly that reason

@jdanbrown
Copy link
Contributor

Ok, clever idea: _typeHint in salat

I think that's not so desirable in this case since we'd have to give up "red" in favor of something like {_typeHint: com.awesome.project.module.Colors, value: "red"}, which is both way more verbose and also exposes the implementation detail of which jvm class is used to model it, which becomes a burdensome leaky abstraction as soon as you want to interop with non-jvm systems.

@imikushin
Copy link
Contributor

Actually, Salat has a concept of context, and type hinting is just one thing in a context. I believe, it can be done in a more elegant way, like detecting what type it is by the fieldset of the JSON document being deserialized. But again, some types might have the same fieldsets, so then the deserializer shall need some hint.

@dircsem
Copy link

dircsem commented Oct 29, 2012

+1

1 similar comment
@JoshZA
Copy link

JoshZA commented Jan 14, 2013

👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests