Re: bug: clojure.contrib.json should not default to use keywords.
Actually, HTTP headers are case-insensitive, so you can't really trust
a regular map of keywords for all purposes. You'd have to reify a
maplike construct (maybe a clojure.lang.IAssociative?) to take care of
case differences. No idea if ring or compojure does this already yet.
I don't see why you'd preserve case when keywordifying headers. After
all, they're case-insensitive.
I believe the stable versions of Compojure/Ring downcase all headers
before keywordifying.
The bleeding-edge Ring gives you options: the httpcore adapter does
this:
headers (reduce
(fn [header-map #^Header header]
(assoc header-map
(-> header .getName lower-case)
(.getValue header)))
{} (seq (.getAllHeaders request)))
giving you a lower-case string map. You can also use Jetty, which I
believe does things case-insensitively.
There is IIRC middleware to do keywordifying.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
On Sun, Feb 28, 2010 at 6:26 PM, Richard Newman wrote:
>> For an example outside of JSON: recently Compojure changed how it
>> works so the HTTP request properties are all converted to keywords by
>> default. I can see the appeal, but now anyone using Compojure has the
>> increased incidental complexity of possible keyword violations.
>> Imagine if you were integrating with PayPal or some system that had
>> HTTP parameters with characters that were not allowed by the Clojure
>> spec. I really don't want to worry about such things when creating
>> software with Clojure.
>
> Per RFC2616, HTTP headers are named by "token"s:
>
> token = 1*
> CHAR =
> CTL =
> separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> |
> "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
>
> As far as I can see, all valid HTTP headers are thus valid Clojure keywords.
> You don't have to worry.
Actually, HTTP headers are case-insensitive, so you can't really trust
a regular map of keywords for all purposes. You'd have to reify a
maplike construct (maybe a clojure.lang.IAssociative?) to take care of
case differences. No idea if ring or compojure does this already yet.
-Phil
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
On Sun, Feb 28, 2010 at 7:34 AM, joshua-choi wrote: > As a small note, according to http://clojure.org/reader, Clojure > keywords and symbols are allowed to contain only alphanumeric > characters, *, +, !, -, _, and ?. Spaces aren’t allowed, but the > keyword function allows them anyway because it doesn’t do any checking > for validity for performance. I’m told that it’s up to the programmer > to make sure that only valid keywords are created. For what it's worth, there's a ticket for this: http://www.assembla.com/spaces/clojure/tickets/17-gc-issue-13-%09validate-in-(keyword-s)-and-(symbol-s) It's been around for a really long time. -Phil -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
On Mar 1, 7:00 am, James Reeves wrote: > On Mar 1, 2:19 am, MarkSwanson wrote: > > > For an example outside of JSON: recently Compojure changed how it > > works so the HTTP request properties are all converted to keywords by > > default. I can see the appeal, but now anyone using Compojure has the > > increased incidental complexity of possible keyword violations. > > Imagine if you were integrating with PayPal or some system that had > > HTTP parameters with characters that were not allowed by the Clojure > > spec. I really don't want to worry about such things when creating > > software with Clojure. > > Huh? Compojure has pretty much always used keywords in parameter maps. > It's certainly not a recent change. Hmm. I recently upgraded an old Clojure release and Compojure at the same time and all code that used keywords to access the nice Compojure data broke. Regrettably I don't have the same setup available so I can't provide more details. It must have been a keyword handling change in Clojure. I find keywords/map integration much less useful/powerful now with the recent master branch, but that's a topic for another thread. Compojure is wonderful btw. Cheers. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
On 2 March 2010 01:21, MarkSwanson wrote: > According to the Clojure reader page SP and HT are not allowed. Well, according to Richard's post, they're not allowed in HTTP header names either: On 1 March 2010 03:26, Richard Newman wrote: > Per RFC2616, HTTP headers are named by "token"s: > > token = 1* Sincerely, Michał -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
> separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" |
> <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
>
> As far as I can see, all valid HTTP headers are thus valid Clojure
> keywords. You don't have to worry.
According to the Clojure reader page SP and HT are not allowed.
Also, I've re-read the reader page and fail to see why you would say
any of the other separators are allowed.
To be sure I'm looking at the correct place, I'm looking at:
http://clojure.org/reader (Reader forms -> Symbols)
Cheers.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
On Mar 1, 2:19 am, MarkSwanson wrote: > For an example outside of JSON: recently Compojure changed how it > works so the HTTP request properties are all converted to keywords by > default. I can see the appeal, but now anyone using Compojure has the > increased incidental complexity of possible keyword violations. > Imagine if you were integrating with PayPal or some system that had > HTTP parameters with characters that were not allowed by the Clojure > spec. I really don't want to worry about such things when creating > software with Clojure. Huh? Compojure has pretty much always used keywords in parameter maps. It's certainly not a recent change. For libraries like c.c.json, I agree with you and Stuart, in that the keys should be strings. In fact, I recently argued in the ring-clojure group that the Ring parameter middleware should also use strings, for pretty much the same reasons you have done. Compojure is a slightly different case, because it's a high-level framework, rather than a low-level library. There's a trade-off between convenience and access to low level details. Still; in Compojure 0.4.0 there will be the option of dropping back down to Ring for more direct access to the parameter map if one wishes. - James -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
For an example outside of JSON: recently Compojure changed how it
works so the HTTP request properties are all converted to keywords by
default. I can see the appeal, but now anyone using Compojure has the
increased incidental complexity of possible keyword violations.
Imagine if you were integrating with PayPal or some system that had
HTTP parameters with characters that were not allowed by the Clojure
spec. I really don't want to worry about such things when creating
software with Clojure.
Per RFC2616, HTTP headers are named by "token"s:
token = 1*
CHAR =
CTL= DEL (127)>
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" |
<"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
As far as I can see, all valid HTTP headers are thus valid Clojure
keywords. You don't have to worry.
-R
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
On Feb 28, 10:34 am, joshua-choi wrote: > As a small note, according tohttp://clojure.org/reader, Clojure > keywords and symbols are allowed to contain only alphanumeric > characters, *, +, !, -, _, and ?. Spaces aren’t allowed, but the > keyword function allows them anyway because it doesn’t do any checking > for validity for performance. I’m told that it’s up to the programmer > to make sure that only valid keywords are created. Thanks for those details. > I agree that clojure.contrib.json should default to string keys, > because keywords are so limited. The thing is, when > clojure.contrib.json *does* convert JSON keys into Clojure keywords, > should it check for validity and fail when it cannot create a valid > keyword? I personally would really appreciate the check, and fail with a sane message. Ultimately, I believe that allowing keywords to be created that violate the language spec is an error and a meaningful error should be thrown. I believe correctness should be more important than speed when core language functionality is concerned. The current situation is that I can legally create Clojure structs that fail to serialize correctly. This is a fundamental component of the language that simply must work correctly. If not, incidental complexity is increased. For an example outside of JSON: recently Compojure changed how it works so the HTTP request properties are all converted to keywords by default. I can see the appeal, but now anyone using Compojure has the increased incidental complexity of possible keyword violations. Imagine if you were integrating with PayPal or some system that had HTTP parameters with characters that were not allowed by the Clojure spec. I really don't want to worry about such things when creating software with Clojure. I'm starting to think that perhaps keywords should only be used in Clojure source code as syntactic sugar to access maps - but the recent changes to Clojure have made them less useful in this regard because maps now have to actually contain keywords instead of the keyword name string. I think this is something that could be a constant source of difficulty with Clojure. I'm curious what others think. Cheers. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
As a small note, according to http://clojure.org/reader, Clojure
keywords and symbols are allowed to contain only alphanumeric
characters, *, +, !, -, _, and ?. Spaces aren’t allowed, but the
keyword function allows them anyway because it doesn’t do any checking
for validity for performance. I’m told that it’s up to the programmer
to make sure that only valid keywords are created.
I agree that clojure.contrib.json should default to string keys,
because keywords are so limited. The thing is, when
clojure.contrib.json *does* convert JSON keys into Clojure keywords,
should it check for validity and fail when it cannot create a valid
keyword?
On Feb 27, 3:24 pm, MarkSwanson wrote:
> Actually, I shouldn't have worded this as a json issue. It's really a
> core problem that keywords with spaces can't be serialized/
> deserialized.
> A keyword is basically a String, and the language definition does not
> preclude keywords from having spaces.
> (keyword "a b c") works, and so does (get m (keyword "a b c")) - on an
> appropriately created map
>
> Cheers.
>
> On Feb 27, 3:55 pm, MarkSwanson wrote:
>
>
>
> > Hello,
>
> > Consider the following valid JSON:
>
> > Clojure=> (def mq "{\"Question one\":\"test\"}")
> > #'user/mq
> > Clojure=> (read-json mq)
> > {:Question one "test"}
>
> > So the default behaviour fails to work correctly for a common case.
>
> > The Clojure failure is not exactly obvious either:
>
> > (read-string (str mq))
>
> > request failed java.lang.RuntimeException:
> > java.lang.ArrayIndexOutOfBoundsException: 19
> > at clojure.lang.RT.readString(RT.java:1220)
> > at clojure.core$read_string__4163.invoke(core.clj:2517)
>
> > I also tried with print-dup and it fails the same way:
> > =>(def ms (new StringWriter))
> > =>(print-dup mq ms)
> > =>(. ms toString)
> > "#=(clojure.lang.PersistentArrayMap/create {:Question one \"test\"})"
> > =>(read-string (. ms toString))
> > # > java.lang.ArrayIndexOutOfBoundsException: 3 (REPL:65)>
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
I use c.c.json heavily in my project and I kind of agree, it should be strings
since in the json definition keys have to be strings, only problem is
serialization as in how to serialize a keyword them?
Regards,
Heinz
On Feb 28, 2010, at 15:36 , Stuart Sierra wrote:
> Mark,
>
> Thank you! I argued for this for months, but everyone kept insisting
> on keywords by default. Now you just have to convince the other 2
> people who actually use clojure.contrib.json.
>
> -SS
>
>
> On Feb 27, 3:55 pm, MarkSwanson wrote:
>> Hello,
>>
>> Consider the following valid JSON:
>>
>> Clojure=> (def mq "{\"Question one\":\"test\"}")
>> #'user/mq
>> Clojure=> (read-json mq)
>> {:Question one "test"}
>>
>> So the default behaviour fails to work correctly for a common case.
>>
>> The Clojure failure is not exactly obvious either:
>>
>> (read-string (str mq))
>>
>> request failed java.lang.RuntimeException:
>> java.lang.ArrayIndexOutOfBoundsException: 19
>> at clojure.lang.RT.readString(RT.java:1220)
>> at clojure.core$read_string__4163.invoke(core.clj:2517)
>>
>> I also tried with print-dup and it fails the same way:
>> =>(def ms (new StringWriter))
>> =>(print-dup mq ms)
>> =>(. ms toString)
>> "#=(clojure.lang.PersistentArrayMap/create {:Question one \"test\"})"
>> =>(read-string (. ms toString))
>> #> java.lang.ArrayIndexOutOfBoundsException: 3 (REPL:65)>
>
> --
> 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 with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
Mark,
Thank you! I argued for this for months, but everyone kept insisting
on keywords by default. Now you just have to convince the other 2
people who actually use clojure.contrib.json.
-SS
On Feb 27, 3:55 pm, MarkSwanson wrote:
> Hello,
>
> Consider the following valid JSON:
>
> Clojure=> (def mq "{\"Question one\":\"test\"}")
> #'user/mq
> Clojure=> (read-json mq)
> {:Question one "test"}
>
> So the default behaviour fails to work correctly for a common case.
>
> The Clojure failure is not exactly obvious either:
>
> (read-string (str mq))
>
> request failed java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: 19
> at clojure.lang.RT.readString(RT.java:1220)
> at clojure.core$read_string__4163.invoke(core.clj:2517)
>
> I also tried with print-dup and it fails the same way:
> =>(def ms (new StringWriter))
> =>(print-dup mq ms)
> =>(. ms toString)
> "#=(clojure.lang.PersistentArrayMap/create {:Question one \"test\"})"
> =>(read-string (. ms toString))
> # java.lang.ArrayIndexOutOfBoundsException: 3 (REPL:65)>
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: bug: clojure.contrib.json should not default to use keywords.
Actually, I shouldn't have worded this as a json issue. It's really a
core problem that keywords with spaces can't be serialized/
deserialized.
A keyword is basically a String, and the language definition does not
preclude keywords from having spaces.
(keyword "a b c") works, and so does (get m (keyword "a b c")) - on an
appropriately created map
Cheers.
On Feb 27, 3:55 pm, MarkSwanson wrote:
> Hello,
>
> Consider the following valid JSON:
>
> Clojure=> (def mq "{\"Question one\":\"test\"}")
> #'user/mq
> Clojure=> (read-json mq)
> {:Question one "test"}
>
> So the default behaviour fails to work correctly for a common case.
>
> The Clojure failure is not exactly obvious either:
>
> (read-string (str mq))
>
> request failed java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: 19
> at clojure.lang.RT.readString(RT.java:1220)
> at clojure.core$read_string__4163.invoke(core.clj:2517)
>
> I also tried with print-dup and it fails the same way:
> =>(def ms (new StringWriter))
> =>(print-dup mq ms)
> =>(. ms toString)
> "#=(clojure.lang.PersistentArrayMap/create {:Question one \"test\"})"
> =>(read-string (. ms toString))
> # java.lang.ArrayIndexOutOfBoundsException: 3 (REPL:65)>
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
bug: clojure.contrib.json should not default to use keywords.
Hello,
Consider the following valid JSON:
Clojure=> (def mq "{\"Question one\":\"test\"}")
#'user/mq
Clojure=> (read-json mq)
{:Question one "test"}
So the default behaviour fails to work correctly for a common case.
The Clojure failure is not exactly obvious either:
(read-string (str mq))
request failed java.lang.RuntimeException:
java.lang.ArrayIndexOutOfBoundsException: 19
at clojure.lang.RT.readString(RT.java:1220)
at clojure.core$read_string__4163.invoke(core.clj:2517)
I also tried with print-dup and it fails the same way:
=>(def ms (new StringWriter))
=>(print-dup mq ms)
=>(. ms toString)
"#=(clojure.lang.PersistentArrayMap/create {:Question one \"test\"})"
=>(read-string (. ms toString))
#
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
