On Jan 28, 2012, at 3:58 PM, Allen Wirfs-Brock wrote:
Since most implementations already seem to have special mechanism for giving
magic behavior to certain properties I would expect them to use some of
those mechanisms here.
No - in JSC I'm pretty sure it's going to be faster and cleaner to
Why can't we define a JSON.clone() or .deepClone() which would only
clone properties that are primitives, object or array. If they are
(instanceof) array, copy index properties and length value and create
new array with that information. If object, create new object and copy
all properties with
On 28 January 2012 22:51, Mark S. Miller erig...@google.com wrote:
Just because an object is provided as part of the host environment does
*not* make it a host object. Given your statements above, I suspect that
the Node objects you have in mind are all simply native objects provided by
the
Since all these candidates can be provided by libraries, this seems like an
area where libraries can explore and compete. If/once a consensus emerges
from such a competition, then we can revisit whether there's really any
reason to standardize.
If we were talking about this in time to prevent or
Le 29/01/2012 19:05, Peter van der Zee a écrit :
Why can't we define a JSON.clone() or .deepClone() which would only
clone properties that are primitives, object or array. If they are
(instanceof) array, copy index properties and length value and create
new array with that information. If
On Sun, Jan 29, 2012 at 1:23 PM, David Bruant bruan...@gmail.com wrote:
Based on your description, it seems that the definition would be:
JSON.clone = function(o){
return JSON.parse(JSON.stringify(o));
}
Or possibly:
JSON.clone = function(o, opt_reviver, opt_replacer) {
return
On Sun, Jan 29, 2012 at 7:23 PM, David Bruant bruan...@gmail.com wrote:
Based on your description, it seems that the definition would be:
JSON.clone = function(o){
return JSON.parse(JSON.stringify(o));
}
Yes. You can debate whether it should remove properties it can't
serialize completely,
With your last two implementations, you don't keep cyclic references.
On Sun, Jan 29, 2012 at 7:39 PM, Peter van der Zee e...@qfox.nl wrote:
On Sun, Jan 29, 2012 at 7:23 PM, David Bruant bruan...@gmail.com wrote:
Based on your description, it seems that the definition would be:
JSON.clone =
Here is a first cut at some improved terminology:
ECMAScript Object - an object whose primitive semantics are specified by the
ECMAScript specification
Foreign Object - an object whose primitive semantics differ from those
specified by the ECMAScript specification
By primitive semantics I mean
On Jan 28, 2012, at 8:04 PM, Mark S. Miller wrote:
Can we leave magical out of a spec convo?
It was intended only for humorous emphasis. But even magical and non
magical would be less confusing than the current terminology!
In some PL research circles, they use exotic as a somewhat less
On Jan 29, 2012, at 12:40 AM, Gavin Barraclough wrote:
On Jan 28, 2012, at 3:58 PM, Allen Wirfs-Brock wrote:
Since most implementations already seem to have special mechanism for giving
magic behavior to certain properties I would expect them to use some of
those mechanisms here.
No -
On Jan 28, 2012, at 12:28 AM, Herby Vojčík wrote:
The proposal for | cites these usage examples:
- Setting the prototype of a function to something other than
Function.prototype
let f = EnhancedFunctionPrototype | function () {}
- Parrallel constructor/instance prototype chains
On Sun, Jan 29, 2012 at 7:50 PM, Xavier MONTILLET
xavierm02@gmail.com wrote:
With your last two implementations, you don't keep cyclic references.
I did not intend to. In fact, my intention was to have a clean
object with just structure (objects and arrays) and primitives.
Nothing else,
I think it should keep it. Douglas did something to allow cyclic
references ( https://github.com/douglascrockford/JSON-js/blob/master/cycle.js
) and he probably wouldn't have done that if it had no use. Plus
you're talking of cloning data structures and a graph is one.
And if you do not allow
Hi Allen,
On Jan 29, 2012, at 4:25 PM, Allen Wirfs-Brock wrote:
There are no rules that constrain [[Put]] in this manner you are suggesting.
Sorry, perhaps my comments were unclear. The observation I was intending to
highlight was only that the current behaviour of [[Put]] will be to call
15 matches
Mail list logo
