haxe.JSON

[Nicolas Cannasse]

Hi,

I've added a haxe.JSON class to SVN trunk, you can test it with both
2.08 and SVN build here :

http://haxe.googlecode.com/svn/trunk/std/haxe/JSON.hx

So far I've only implemented JSON.stringify (with no optional
parameters). It's a complete rewrite but I've based some behaviors on
hxJson2 haxelib library.

I'm interested in testing/benchmarks/suggestions.

Please note that for flash 10.3+ we will use native JSON flash api, and
for JS we will use global JSON api if available at runtime. You can
force usage of haxe implementation by compiling with -D haxeJSON

Best,
Nicolas

[Andy Li]

A quick comment: since it is Xml, not XML, should it be Json instead of JSON?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

[Nicolas Cannasse]

Le 19/02/2012 12:40, Andy Li a �crit :

> A quick comment: since it is Xml, not XML, should it be Json instead of
> JSON?

I've thought about it but all the native API uses JSON...

Best,
Nicolas

[Marc Weber]

mootools is usingc JSON.(encode|decode)
jquery is using parseJSON
json.org is calling it JSON as well.

'\\'.code which syntax is this? I haven't seen it before? is code a
function !? There is no using. Or is it a special trick built into the
compiler?

About parsing: For neko regex are fastest. I did some benchmarks ago -
it was still a lot slower than a .fastCharAt implementation could be
(using JS, CPP backends ..) One of the problems I (and Stephane's parser
combinator library encountered) was that there is no efficient way to
apply a regex at char position X. eg PHP provides offset feature.
Maybe it should be added to regex class

See my attempts here:
https://groups.google.com/group/haxelang/browse_thread/thread/313c42f3349af6a5

Also I think we should fix the UTF-8 issue I talked about earlier first.
I've made some progress - I'm pretty sure that the way to go is "keep
thing simple" - which means only allow char8 or unicode strings at the
same time - because HaXe allows var s += "abc" like syntax.
Its what the CPP backend does anyway. I haven't had time to finish the
patch yet :(

However I had about 120MB of json log files I tried processing - and
fastest was using PHP - it was fast to write and ran fast (because
json_decode in PHP is native C function).

anyway for different target different strategies are required unless non
optimal speed is fine (which probably applies to many web related
systems).

Marc Weber

[Juraj Kirchheim]

On Sun, Feb 19, 2012 at 12:46 PM, Nicolas Cannasse
<ncan...@motion-twin.com> wrote:

> Le 19/02/2012 12:40, Andy Li a écrit :
>
>> A quick comment: since it is Xml, not XML, should it be Json instead of
>> JSON?
>
>
> I've thought about it but all the native API uses JSON...

By extension of that argument, Xml should be renamed to XML in haXe :P

But more seriously, the std lib uses mixed case for acronyms: Http,
Xml, Rtti, Mysql, HtmlEditor, Gc.
It takes a while to get used to, but its ok. Also JSONHTTPAPIURL
doesn't really read that well :D
But most importantly, I think it should just be consistent, so I
"vote" for `Json` ;)

As for haXe 3 I suggest SHA1 > Sha1, JSGenApi > JsGenApi, and also one
might rename all that flash api stuff with @:native (although I think
it's ok to accept that Adobe has it's own personal taste).

Regards,
Juraj

[Nicolas Cannasse]

Le 19/02/2012 13:01, Marc Weber a �crit :

> mootools is usingc JSON.(encode|decode)
> jquery is using parseJSON
> json.org is calling it JSON as well.
>
> '\\'.code which syntax is this? I haven't seen it before? is code a
> function !? There is no using. Or is it a special trick built into the
> compiler?

Yes, it' s special trick : it will compile into the corresponding
character code integer. I've added it to
http://haxe.org/manual/tips_and_tricks

Best,
Nicolas

[Andy Li]

I think making the haxe std lib as consistent as possible is the way to go, ie. use "Json".

We already have @:native for mapping api difference for a long time, so I don't think it is a problem.

The python guys always make their API/bindings "pythonic" instead of sticking to the native naming, and the resulting core/3rd party lib is pretty consistent and clean.

I guess promoting a single haxe specific style as "haxy" wouldn't be a bad idea.

Best,

Andy

[Nicolas Cannasse]

Le 19/02/2012 13:01, Marc Weber a �crit :

> About parsing: For neko regex are fastest. I did some benchmarks ago -
> it was still a lot slower than a .fastCharAt implementation could be
> (using JS, CPP backends ..) One of the problems I (and Stephane's parser
> combinator library encountered) was that there is no efficient way to
> apply a regex at char position X. eg PHP provides offset feature.
> Maybe it should be added to regex class
>
> See my attempts here:
> https://groups.google.com/group/haxelang/browse_thread/thread/313c42f3349af6a5

I'm mostly interested in having a standard standalone "compatibility"
version that runs fast enough on all targets and is easy to maintain.

We will of course use faster native implementation when it's available.

Best,
Nicolas

[Heinz Hölzer]

I would prefer Json too and it's consistent with the other std types.

best,
h

[Philipp Klose]

+1, I really like to have JSON in standard library.

There is also a native PHP extension for JSON decoding and encoding and
as far as I remembered it worked nicely together with hxJson2 (or
json4haxe, an older attempt of mine to make hxJson2 more hax'ish -
https://github.com/TheHippo/json4haxe, unfinished).

Philipp

[Juraj Kirchheim]

Nicolas, it seems you renamed the file and added the @:native but
haven't actually renamed the class ;)

2012/2/19 Heinz Hölzer <heinz....@googlemail.com>:

[Juraj Kirchheim]

I think it is important to have a *standard-compliant* pure-haXe
encoder and decoder, that can also run in a *permissive* mode, i.e.
allow comments, identifiers instead of strings for field names and
trailing commas in object/array declarations, much like as3corelib's
decoder does it. Of course one can get the permissive mode from
hscript if needed, but I think it is well within the scope of the
standard library.

From there, we can investigate all sorts of native possibilities to
speed things up, but I don't think this is really critical at the
current stage. For now we shouldn't forget that having a working
solution with a stable API is infinitely better than what we had so
far and provides all the room for performance improvement that we may
need.

Regards,
Juraj

[Philipp Klose]

The current implementation uses native code for Flash 10.3+ and
JavaScript (if available), so on these platforms you currently just get
standard JSON decoding and encoding, so it would not harm to also use
PHP native functions.

If you would like the haXe class to work with non-standard JSON (like
identifiers instead of strings), you need to stick with the haXe
implementation to get the same behaviour on all platforms.

Basically there are two possible ways to go:
a) Just pure standard JSON with fast speed through native functions if
available
b) Fanzy JSON alike format encoder / decoder, with a pure haXe
implementation

I personally would prefer to go with a). It fits for most appliances and
if you want something besides the standard you always could use a library.

Philipp

[Nicolas Cannasse]

Le 19/02/2012 18:13, Juraj Kirchheim a �crit :

> Nicolas, it seems you renamed the file and added the @:native but
> haven't actually renamed the class ;)

Fixed, the file is now :
http://haxe.googlecode.com/svn/trunk/std/haxe/Json.hx

Best,
Nicolas

[Nicolas Cannasse]

Le 19/02/2012 13:01, Marc Weber a �crit :

> Also I think we should fix the UTF-8 issue I talked about earlier first.
> I've made some progress - I'm pretty sure that the way to go is "keep
> thing simple" - which means only allow char8 or unicode strings at the
> same time - because HaXe allows var s += "abc" like syntax.
> Its what the CPP backend does anyway. I haven't had time to finish the
> patch yet :(
>
> However I had about 120MB of json log files I tried processing - and
> fastest was using PHP - it was fast to write and ran fast (because
> json_decode in PHP is native C function).

I tried using json_encode for PHP but it converts arrays into the
following { null : [<array content>], length : 2 } (because of haXe
wrapper ?). I guess the issue is reversed by json_decode : you don't get
proper haXe Arrays.

Any efficient way to deal with it ?

Best,
Nicolas

[Franco Ponticelli]

I can measure if native + array wrapping is still faster than the pure haxe implementation.

Franco

On Saturday, March 3, 2012, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

[clemos]

If you make _hx_array extend ArrayObject
(http://fr2.php.net/manual/en/class.arrayobject.php), json_encode
returns :
{"0":"foo","1":"bar"}
Maybe it would be better, in general, to have HaXe arrays extend
ArrayObject ? I guess it would have side effects, though

----------
class _hx_array extends ArrayObject implements ArrayAccess, IteratorAggregate {
var $»a;
var $length;
function __construct($a = array()) {
$this->»a = $a;
$this->length = count($a);
parent::__construct($a);
}
...
---------

Cheers,
Clément

[Franco Ponticelli]

I'm pretty sure there are side effects to that.

Franco

[Nicolas Cannasse]

Le 03/03/2012 17:31, clemos a �crit :

> If you make _hx_array extend ArrayObject
> (http://fr2.php.net/manual/en/class.arrayobject.php), json_encode
> returns :
> {"0":"foo","1":"bar"}

Well, that's not what we want here : we need ["foo","bar"] ;)

Nicolas

[Nicolas Cannasse]

Le 03/03/2012 17:17, Franco Ponticelli a �crit :

> I can measure if native + array wrapping is still faster than the pure
> haxe implementation.

Yes thanks that would be helpful. Fell free to complete haxe.Json with
optimized PHP implementation ;)

Best,
Nicolas

[Nicolas Cannasse]

Le 19/02/2012 12:26, Nicolas Cannasse a �crit :

> Hi,
>
> I've added a haxe.JSON class to SVN trunk, you can test it with both
> 2.08 and SVN build here :

Followup : there is now Json.parse as well.

I'm interested in testing/benchmarks/feedback for the different platforms.

You can use -D haxeJSON to force the usage of the haxe JSON class
instead of using native one (on JS when available on for Flash 11+)

http://haxe.googlecode.com/svn/trunk/std/haxe/Json.hx

Best,
Nicolas

[Arystanbek Dyussenov]

Hi Nicolas,

I'm a new user of Haxe (transitioned from ActionScript).  I've written a haxe.Json subclass that overrides the fieldsString() method to output human-readable JSON with indentations and new line separations. Code: https://gist.github.com/3931793, sample output: https://gist.github.com/3931736.

I wrote it because I needed a way to export JSON that can be edited by hand. I think it could be added to the Haxe library in one form or another to allow other developers to benefit from it.

Best regards,

Arystan

воскресенье, 19 февраля 2012 г., 17:26:48 UTC+6 пользователь Nicolas Cannasse написал:

[Nicolas Cannasse]

Le 22/10/2012 16:35, Arystanbek Dyussenov a écrit :
> Hi Nicolas,
>
> I'm a new user of Haxe (transitioned from ActionScript). I've written a
> haxe.Json subclass that overrides the fieldsString() method to output
> human-readable JSON with indentations and new line separations

> (attached). Sample output: https://gist.github.com/3931736.

>
> I wrote it because I needed a way to export JSON that can be edited by
> hand. I think it could be added to the Haxe library in one form or
> another to allow other developers to benefit from it.

That's interesting, but I'm not sure if we can include it since it would
only be compatible when we don't use the natively supported JSON
implementation. Tell me if you have some idea.

Best,
Nicolas

[Arystanbek Dyussenov]

понедельник, 22 октября 2012 г., 20:47:47 UTC+6 пользователь Nicolas Cannasse написал:

Yes, native pretty print option is not available in JS and only available in PHP sincle version 5.4. Don't see a solution other than making it available only when haxeJSON is defined. Do you think I should add this class to http://lib.haxe.org?

The link was missing from the original message: https://gist.github.com/3931793.

 

Best,
Nicolas

[Arystanbek Dyussenov]

I think that two goals, human readable JSON and fast JSON output can be mutually exclusive.

It is, if a developer wants to produce a human editable JSON file, it will more frequently be a small JSON file where speed differences between native and haxe implementations is imperceptible.

Taking this into account, I suggest to replace the compile-time haxeJSON option with runtime options (that can be mutually exclusive), one to enable native implementation usage and another to enable pretty printing.

Best regards,

Arystan

воскресенье, 19 февраля 2012 г., 17:26:48 UTC+6 пользователь Nicolas Cannasse написал: