documents current behaviour of {labels, ...} option, should not be regarded as a stable api

This commit is contained in:
alisdair sullivan 2011-12-01 22:25:49 -08:00
parent fb1b21c67c
commit cef8ccd5c2

View file

@ -24,10 +24,20 @@ types:
* `JSON` = `binary()`
* `Term` = `[]` | `[{}]` | `[any()]`
* `Opts` = `[]` | `[loose_unicode]`
* `Opts` = `[]` | `[Opt]`
* `Opt` =
- `loose_unicode`
- `labels`
- `{labels, Label}`
- `Label` =
* `binary`
* `atom`
* `existing_atom`
if the option `loose_unicode` is present invalid codepoints are replaced with `u+FFFD`. default behaviour is a `badarg` error
the option `labels` controls how keys are converted from json to erlang terms. `binary` does no conversion beyond normal escaping. `atom` converts keys to erlang atoms, and results in a badarg error if keys fall outside the range of erlang atoms. `existing_atom` is identical to `atom`, except it will not add new atoms to the atom table
**converting erlang terms to json**
@ -95,10 +105,6 @@ all erlang strings are represented by *valid* `utf8` encoded binaries
this implementation performs no normalization on strings beyond that detailed here. be careful when comparing strings
**keys**
keys are functionally identical to strings. see `string` above
**true, false and null**
the json primitives `true`, `false` and `null` are represented by the erlang atoms `true`, `false` and `null`. suprise
@ -109,7 +115,7 @@ json arrays are represented with erlang lists of json values as described in thi
**objects**
json objects are represented by erlang proplists. the empty object has the special representation `[{}]` to differentiate it from the empty list. ambiguities like `[true, false]` prevent using the shorthand form of property lists using atoms as properties. all properties must be tuples. all keys must be encoded as in `string`, above
json objects are represented by erlang proplists. the empty object has the special representation `[{}]` to differentiate it from the empty list. ambiguities like `[true, false]` prevent using the shorthand form of property lists using atoms as properties. all properties must be tuples. all keys must be encoded as in `string`, above, or as atoms (which will be escaped and converted to binaries for presentation to handlers)
## acknowledgements ##