JSON decoding

Nicolas Cannasse ncannasse at motion-twin.com
Fri Nov 3 01:09:58 PST 2006

> So my opinion, even if narrow focused, ok having JSON as standard in
> ES4 is good,
> but having tools inside the language to be able to implement other
> serialization/deserialization mecanism is better.
> Something as flash.utils.describeType in a little more advanced way and
> defined as standard in ES4 would be perfect imho,
> but ok perharps I'm asking too much.

There are two kind of serialization there.
- runtime serialization, based on values
- metadata serialization, based on compile-time types

JSON is a runtime-one, it's based on values and does not require
additional type informations. However, it can't handle classes or custom
unserialize methods.

haXe Serialization is also a runtime serialization, but uses some
additional informations generated in JS/SWF code (such as classes name).
It enables then to (un)serialize classes instances as well. Classes are
reference by-name and only the instance fields are serialized (not the
prototype ones). Plus, haXe Serialization supports a good number of
standard types : arrays, but also dates, lists, enums and exceptions.

For these two kind of serialization, no extra runtime type infos are
required than the ones already available. However they have one big flaw
which is the lack of ability to check that a given unserialized value
entirely matches a given type (structurally). You can do an additional
check phase but it needs to be provide a type-description that is
painful to write. That's in such cases (and for introspection) that a
type description is available.

Flash9 adds the describeType function. Because the information is
already available in the bytecode, it comes for free. That's not the
case for other haXe supported languages (JS and Neko), so such XML
informations is now optionaly generated if the class implements
haxe.rtti.Infos. The good thing is that the XML also includes
documentation comments.

Such additional type informations can be used as type signature when
checking an untrusted data source in order to validate the data, but is
not mandatory for serialization.

However I agree that a good Reflection/Introspection API is very
important in a programming languages. For example, haXe have
http://haxe.org/api/Reflect and http://haxe.org/api/Type APIs which can
be used to implement a lot of different libraries.

Again, I'm in favor of opening the ES4 language as much as possible by
providing the base API that needs VM-level support.


More information about the Es4-discuss mailing list