- From: David Bruant <david.bruant@labri.fr>
- Date: Wed, 06 Jun 2012 22:52:32 +0200
- 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