Getter is imperative, it may be lot harder to make it safe; and its semantics would differ whether used in JSON / in eval (can lead to nasty long-hidden bugs). Path is declarative (and fails fast in eval).

If one would want to make it more code-like, then something should be devised which has the same meaning in code as well as in JSON. Like:

    {
         x:{
             a:{
                 obj:[]
             },
             b: [-1].a
         }
    }

where [n] is reserved form (other may be used) to contain stack of nested currently defined literals in the actual lexical scope, possible to index by positive (absolute) as well as negative (relative); so it could also be [0].x.a or [1].a (geez, it can be made even generally to access all nested lexical scopes, to access its local variables if it is code; but then possibly only negative index would be permitted..., it is hard to define where positive should start, at file level, probably).

gaz Heyes wrote:
Wouldn't it be easier to extend JSON to support a getter with a function
that refers to "this"?

o={a:123, get b(){return this.a}};o.b

On 5 March 2012 10:50, 程劭非 <[email protected]
<mailto:[email protected]>> wrote:

    Hi, everyone,

    As you know, JSON API will throw a syntax error when trying to
    stringify a object with circular reference.But indeed the feature
    "serializing/unserializing object with circular reference" is
    needed.(eg. when storing a graph,or status machine)

    I am working on a JS implement of parse/stringify to support a “path
    grammar” in JSON. It looks like the following:
    --------------------------------
    // this will produce a object with it's property “x” reference to it
    self
    {
         x:path(/)
    }
    --------------------------------
    //also relative path is supported
    {
         x:{
             a:path(../x),
             b:path(x)
         }
    }
    --------------------------------
    //ref to deeper object
    {
         x:{
             a:{
                 obj:[]
             },
             b:path(/x/a/obj)
         }
    }
    --------------------------------
    // path could also point to a none-object value
    {
         a:11,
         b:path(/a)
    }
    --------------------------------
    // path ref to a path node will get undefined, there is no way
    to recurse
    {
         a:path(/), //the root object
         b:path(/a) //undefined
    }
    ----------------------------------

    ( The project is located at
    https://github.com/wintercn/JSONplus. in which JSON.pareseEx and 
JSON.stringifyEx passes all test262 API cases except the ones related to 
circular reference. )


    I was wondering if the future version of ECMAScript could support
    this grammar or something like this to
    enable serializing/unserializing object with circular reference. It
    will be a good news for ones working on complex data structure.

    PS. Another known way of descripting object with circular reference
    is using sharp variable
    <https://developer.mozilla.org/en/Sharp_variables_in_JavaScript> in
    object literal . But there are several problems:
    1. The id in sharp variable has to be unique. Combining two objects
    with conflicted ids will be hard work.
    2. Sharp variable is sensitive to the order of object properties. A
    assignment must appear before its first usage. But path do not have
    such requirement.Since the order of properties defined in JSON would
    (especially) affect enumerate (for.. in) order, making a
    order-independent reference grammar is a must.
    3. Sharp variable requires assignment operator, and hence assignment
    expression and even continuous assignment expression. Adding this
    feature to JSON increases the complexity of its grammar a lot.




    Thanks,
    Shaofei Cheng


    _______________________________________________
    es-discuss mailing list
    [email protected] <mailto:[email protected]>
    https://mail.mozilla.org/listinfo/es-discuss



------------------------------------------------------------------------

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to