RE: [WebIDL] toJSON



> -----Original Message-----
> From: David Bruant [mailto:david.bruant@labri.fr]
> 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. 

Your average element has a parentNode, firstChild, and childNodes collection (to name a few). Your algorithm doesn't handle collections, and fail to parse any pair of adjacent nodes in the tree due to the cycle they have with each other.

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) 

Similar, but not exact. For performance and performance.timing IE9 only stringifys the DOM attributes, not any random property you put on the objects or their prototypes.

If it's an equivalent algorithm, what do you think of
> generalizing it to all WebIDL constructors?

I think we are going to find that a lot of different objects have differing needs or desires in what they choose to stringify (consider the element example earlier). Each object that wants this behavior would likely want to specify exactly what it does. However, having some guidelines around whether user-defined properties on objects are included/excluded would help bring some uniformity to the design.

Received on Thursday, 7 June 2012 20:14:17 UTC