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 yo
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 comp
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
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
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:
>
> to
> 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 a
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
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 integrat
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
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 to
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
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=>
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 (ke
13 matches
Mail list logo
