By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,635 Members | 2,188 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,635 IT Pros & Developers. It's quick & easy.

slightly more powerful JSON

P: n/a
Hello group,

I have been using JSON for a while and it has made many things a breeze.
However, JSON does not natively describe certain things like pointers
and custom types. I created a simple JSON extension that allows
cross-references, and I'm asking for your thoughts on a simple type system.

I've dubbed this variation RJSON (Red's JSON) for lack of a shorter
name. Here's how it works right now:

The JSON way to encode a few people might be :

{ "doug" : { "friends" : [ { "ryan" ] },
"ryan" : { "friends" : [ "doug"] } }

that is sort of odd since now doug and ryan's friends are not people,
but are instead strings. An RJSON encoder recognizes object equality
when serializing and encodes the friends with cross-references:

{ "doug" : { "friends" : [
xdecl(0, { "friends" : [ "doug"] } ) ]
"ryan" : xref(0) }

that allows more objects to be better described than in pure JSON. more
sophisticated relationships are allowed, including things like circular
references.

Now for a type system. YAML has a fairly effective type system, and
when I used Ruby I liked how easy it was to dump custom types. YAML is
not ideal for the browser because it requires more extensive parsing.
JSON, on the other hand, is great in the browser because it can be
evaled. The goals of the type system are a syntax that is
Javascript-compatible but simple enough to parse pretty easily. I would
like to combine the quick ability to dump objects that YAML has with the
evaluation speed of JSON.

so consider we have a object type called Person:

function Person(name, email) {
this.name = name;
this.email = email;
}

[ xtype("Person", { "name" : "Doug", "email" : "theeyesofmice@gmail" } ]

the type that is the first argument to xtype is a string descriptor of
the type. the parser can then, for example, look up the type string in
a table that maps type strings to handler functions. A handler that
will initialize person might look like

function(obj) { return new Person(obj.name, obj.email) }

It doesn't have to be a table lookup, though.. it can be any function.

Here's the unsafe parser I currently use:

function marshallRjson(type, arg) {

var lookupTable =

{ 'Person' : function (obj) {

new Person(obj.name, obj.email);

} };

if (lookupTable[type]) {

return lookupTable[type]();

};

};

function evalRjson(rjsonText) {

var xrefTable = { };

var xtypeWithObjects = { };

var xdecl =

function (name, value) {

return xrefTable[name] = value;

};

var xref =

function (name) {

return xrefTable[name];

};

var xtype = marshallRjson;

return eval('(' + rjsonText + ')');

};

All this code is, basically, is introducing the ability to call a few
functions inside would-be JSON code. The real idea behind these
features is sharing object representations between an application server
and client in a more sophisticated way than easily possible right now.
neat? not? suggestions?

thanks for your time,
Red Daly
International Object Database
[Aside] This is probably one of the less interesting webby things I'm
working on right now. Cooler is an alternative object system based on
generic functions and class-based inheritance. I am just starting to
look into the applications of lazy evaluation for web programming.

An example implementation of an encoder for RJSON is available here:
http://suavescript.googlecode.com/sv...src/rjson.lisp
Jan 3 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Red Daly wrote:
The JSON way to encode a few people might be :

{ "doug" : { "friends" : [ { "ryan" ] },
"ryan" : { "friends" : [ "doug"] } }
Does the above evaluate correctly in a browser? I would think it would
need to be:

{ doug : { friends : [ "ryan" ] },
ryan : { friends : [ "doug" ] } }

Cheers
Chad
Jan 3 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.