W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2012

Re: [WebIDL] toJSON

From: David Bruant <david.bruant@labri.fr>
Date: Wed, 06 Jun 2012 22:52:32 +0200
Message-ID: <4FCFC310.9000205@labri.fr>
To: Cameron McCormack <cam@mcc.id.au>
CC: Travis Leithead <travis.leithead@microsoft.com>, Brendan Eich <brendan@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Le 06/06/2012 03:15, Cameron McCormack a écrit :
> Travis Leithead:
>> The larger question (in my mind) is whether toJSON extensions should
>> get syntactic sugar in WebIDL or not. Since they are so similar (in
>> principle) to toString extensions, I'd argue that it would be a good
>> idea. Cameron, what do you think?
>
> I think this sounds like a neat idea.  Two things come to mind:
>
> 1. Is this
Just to clarify here, by 'this', do you mean "turning WebIDL objects
into JSON" or Travis' idea to have syntactic sugar in WebIDL? I'll
assume the former

> just the same as creating a proxy to wrap the object, which
>    just forwards everything as-is, calling Object.freeze on that proxy,
>    and then using that frozen object as the JSON object?
No, first (that's somewhat a nit-pick, but maybe not) in the new direct
proxy design, freezing the proxy would freeze the target which is not
really what we would want.
Also, the point of adding toJSON properties is to make JSON.stringify
useful by default. The aim is to generate a string, so I'm not sure what
you mean by "the JSON object".

For the toJSON, I'm seeing a default algorithm as follow:

    WebIDLConstructor.prototype.toJSON = function toJSON(){
        var acc = {};
        var toTraverse = this;
       
        while(toTraverse){
            // Object.keys to skip non-enumerable properties
            Object.keys(toTraverse).forEach(function(p){
                if(p in acc)
                    return; // shadowed
           
                if(isConstant(p, WebIDLConstructor) || isOperation(p,
WebIDLConstructor))
                    return; // don't need to export these in the JSON
               
                acc[p] = toTraverse[p];
            });
           
            toTraverse = Object.getPrototypeOf(toTraverse);
        }
       
        return JSON.stringify(acc);
    }

I assume some isConstant and isOperation primitive.
I'm a bit worried of cycles for this algorithm. Maybe there is a need to
detect that. Web browsers already implement such a detection for the
native JSON.stringify.
If some properties are themselves objects, the last JSON.stringify will
properly stringify them.

I don't have an IE9 to test against, but does the above algorithm gives
the same result than IE9 on the performance objects? (modulo property
order since its unspecified by ES5)
If it's an equivalent algorithm, what do you think of generalizing it to
all WebIDL constructors?

David
Received on Wednesday, 6 June 2012 20:53:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:06 UTC