Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-string map keys don't work #10

Closed
Nakano37 opened this issue Jul 30, 2010 · 3 comments
Closed

Non-string map keys don't work #10

Nakano37 opened this issue Jul 30, 2010 · 3 comments

Comments

@Nakano37
Copy link

In CollectionTypes.mapFormat the reads and writes functions look like:
{{{
implicit def mapFormat[K, V](implicit fmtk: Format[K], fmtv: Format[V]) : Format[Map[K, V]] = new Format[Map[K, V]] {
def writes(ts: Map[K, V]) = JsObject(ts.map{case (k, v) => ((tojson(k.toString)).asInstanceOf[JsString], tojson(v)(fmtv))})
def reads(json: JsValue) = json match {
case JsObject(m) => Map() ++ m.map{case (k, v) => (fromjsonK(fmtk), fromjsonV(fmtv))}
case _ => throw new RuntimeException("Map expected")
}
}
}}}
The writes is always assuming that the key is a string, doing "k.toString" before passing it to tojson. This is causing problems if you have a class (even a simple wrapper class around string) that is used as the key for the map.

@debasishg
Copy link
Owner

Yeah .. this is intentional. I am not sure what it means to have non string keys in JSON. In JSON keys are always strings. Will appreciate feedback on the possible solution of JSON representation where the key is a class object.

@Nakano37
Copy link
Author

Nakano37 commented Aug 3, 2010

Sorry, I realize that keys need to be strings. Let me try to explain... I ran into this while implementing some serialization code where we had a Map[Wrapper, SomeObject] where Wrapper was an object was an "object Something extends Wrapper("Something")" which allowed us to be more type safe with our keys to the map, rather than just using strings, while still having the string name for serialization. While it worked fine if we overrode toString on Wrapper to just return that passed in name, it would have been nice to be able to have toString continue to give the full name of the class its contents and use a format for returning that string.

Going to close this though because I realize that's probably much more of an edge case than its worth spending time on, thanks.

@debasishg
Copy link
Owner

This is an issue which bothers me off and on. It will be very nice if you give me a concrete example of what you would like to have. I can then see if it can generalized and fitted into the framework. Will wait for your response ..

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants