utf8 output for mochijson2:encode/1 suggestion

[GoogleCodeExporter]

What steps will reproduce the problem?
1. apply encode/1 any unicode string

What is the expected output? What do you see instead?
You'll got \uXXXX sequences
Expected UTF-8 characters as suggested in rfc4627 as a default form.

What version of the product are you using? On what operating system?
last mochiweb source

Please provide any additional information below.
The interoperability issues may occur when using raw utf8 instead of \uXXXX
encoding, but, I think this is rare cases.
Raw utf8 also have many advantages for international language users.

An unofficial patch:
http://wiki.github.com/dmi/erlangine/mochijson2erl-native-utf8-patch

Original issue reported on code.google.com by barah...@gmail.com on 26 Mar 2009 at 1:02

[GoogleCodeExporter]

This patch will not be accepted unless the behavior is optional (and not 
default) because this will break 
backwards compatibility.

Original comment by bob.ippo...@gmail.com on 26 Mar 2009 at 1:04

[GoogleCodeExporter]

Please, give me a suggestion about coding.
Do I have to introduce a new option to the #encoder record?

Original comment by barah...@gmail.com on 26 Mar 2009 at 1:40

[GoogleCodeExporter]

Yeah, that seems like the most reasonable approach

Original comment by bob.ippo...@gmail.com on 26 Mar 2009 at 2:04

[GoogleCodeExporter]

The patch.

Also I have a question: what is the reason to use encoder/1 (with parser and 
closure
function) instead of introducing simple encode(json(), #encoder{}) ?

My view:
advantage is much simplcity.
disadvantage is needing to include file with #encoder{} definition.

Original comment by barah...@gmail.com on 27 Mar 2009 at 7:01

Attachments:

• mochijson2.diff

[GoogleCodeExporter]

Using a record introduces an undesirable compile-time dependency across 
projects. The record is an 
implementation detail, it should not be part of the API. It does not make the 
API better to use a record.

-include(somenewfile.hrl).
record_api() ->
     mochiweb_json2:encode(json(), #encoder{utf8=true}).

proplist_api() ->
    mochiweb_json2:encode(json(), [{utf8, true}]).

Original comment by bob.ippo...@gmail.com on 27 Mar 2009 at 12:21

[GoogleCodeExporter]

Agree for compile-time dependency.

Two comments:

1.Actually proplist_api is:
proplist_api() ->
    Fun = mochijson2:encoder([{utf8, true}]),
    Fun(json()).

2. In situation of parallel computations we'll got each time parsing list-to 
struct
for options. Probably this isn't a big problem.

Hmm... I think I can't suggest any universally better solution here :-)
So I have no anything else to add to my patch...

Original comment by dmi.cher...@gmail.com on 27 Mar 2009 at 12:58

[GoogleCodeExporter]

You can call the returned fun more than once and you can send it to other 
nodes, so there is *no* problem :)

Original comment by bob.ippo...@gmail.com on 27 Mar 2009 at 1:04

[GoogleCodeExporter]

:-)
agree.

Original comment by dmi.cher...@gmail.com on 27 Mar 2009 at 1:17

[GoogleCodeExporter]

applied in r99

Original comment by bob.ippo...@gmail.com on 4 Apr 2009 at 9:54

• Changed state: Fixed

[GoogleCodeExporter]

Many thanks!!!

Original comment by dmi.cher...@gmail.com on 7 Apr 2009 at 10:13