So I made a change which allows passing a map of deserializers instead
of having them initialized globally, it's more or less the same as the
previous version otherwise, let me know if you feel it makes the
reader too complex
http://gist.github.com/565764
here's sample usage with that approach
(
That's a very good point, I can't think of a good way to address that
off top of my head, I agree that passing in a function isn't really
great either.
On Sep 3, 3:17 pm, Stuart Sierra wrote:
> No. I'm talking about collisions when multiple deserialization
> functions are added from different sou
No. I'm talking about collisions when multiple deserialization
functions are added from different sources. It cannot be a global
setting.
-S
On Sep 3, 1:28 pm, Dmitri wrote:
> The problem I was trying to avoid is having to do a second pass over
> the data after it comes out of the parser, it's
The problem I was trying to avoid is having to do a second pass over
the data after it comes out of the parser, it's more expensive and
it's also ugly for nested data structures. Would using defonce- and
defmacro- from clojure-contrib address the problem with namespace
collisions?
On Sep 3, 12:01
You can already extend the Write-JSON protocol to any type. But it
doesn't work in reverse. JSON has no standardized way to express types
beyond Object/Array/String/Number, so any deserialization will always
be application-specific.
-S
On Sep 3, 8:58 am, Baishampayan Ghose wrote:
> > Sorry, I c
> Sorry, I can't accept any patch that modifies behavior globally. What
> happens when two different libraries try to parse JSON with different
> deserializers?
>
> The only thing I would consider is a function that is passed into read-
> json and invoked in read-json-object. But even that seems li
Sorry, I can't accept any patch that modifies behavior globally. What
happens when two different libraries try to parse JSON with different
deserializers?
The only thing I would consider is a function that is passed into read-
json and invoked in read-json-object. But even that seems like adding
u
Thanks, I'll give it a try.
On Aug 25, 12:00 pm, Dmitri wrote:
> I posted the complete file on github herehttp://gist.github.com/549771
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Not
I posted the complete file on github here http://gist.github.com/549771
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient wi
I added the *deserializers* atom, converted read-json-object to a
macro
(def *deserializers* (atom {}))
(defn add-deserializer [k deserializer]
(swap! *deserializers* #(assoc % k deserializer)))
(defn remove-deserializer [k]
(swap! *deserializers* #(dissoc % k)))
(defmacro get-object-reader
I understand the desire to keep the parser clean, but at the same time
the ability to register custom data deserializers would be very
convenient. Would something like the following help with the
performance issue, since if no deserializers were registered there
would only be a one time penalty for
On Aug 23, 9:03 pm, Dmitri wrote:
> Would there be an issue with adding something like that to the
> contrib?
I don't want to add anything that impacts performance in the plain
parsing case.
-S
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To pos
Transforming the data after it comes out of the parser can be
cumbersome with complex data structures though, it would be nice to
have a way for the parser to return the data in the desired format.
I updated clojure.contrib.json with the ability to add custom
deserializers:
(def *deserializers* (
I suppose one could override the (private) read-json-object function
to transform maps after they are read, based on the presence of
certain keys. But that would seriously complicate the reader. It's
probably easier to transform the data after it comes back from the
JSON parser.
-S
On Aug 20,
My concern is more to do with the reader, I think extending writer
works quite well, it would be nice if it was possible to do the same
thing with the reader, so you could specify how to deserialize
specific types of data. Right now it seems to be baked into read-json-
reader and there's no easy wa
Since there is no standard for how to represent dates in JSON, it is
unlikely to be built in. But you can extend the writer with
application-specific date formats.
-S
On Aug 20, 2:15 pm, Dmitri wrote:
> I'm currently using Dan Larkin's clojure-json, and it provides a way
> to serialize and dese
Extending the writer is pretty trivial
(defn write-date [date]
(.format (new java.text.SimpleDateFormat "MMM dd, hh:mm:ss a")
date))
(extend Date Write-JSON
{:write-json write-date})
but it seems like deserializing a date wouldn't be quite so trivial.
--
You received this message beca
17 matches
Mail list logo
