Re: __proto__ security
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
[[DefineOwnProperty]] on a base object that is not the object that logically
contains the 'magic' property, if the __proto__ is specified as a data
descriptor.
E.g.
> Object.prototype.__p__ = 1;
> var a = {};
> a.__p__ = 2;
The [[Put]] of '2' will call the [[DefineOwnProperty]] trap of 'a', not the
object that currently contains a data descriptor for __p__.
Hence (as I think you recognize in your comments), it would not simply be
sufficient to provide an overridden implementation for [[DefineOwnProperty]]
for the object prototype. This does mean that the 'magic' behaviour cannot be
as easily and cleanly encapsulated as it can for Array, where the 'magic'
properties are directly on the base object passed to [[DefineOwnProperty]].
> This seems like a perfectly reasonable way to specify this. As __proto__
> does indeed affect the property access semantics for every object. Of
> course, I'm only talking specification. How you accomplish it in your
> implementation is up to you.
>
> There are other, alternatives.
I'm not questioning for a minute that this is possible – it certainly is – I'm
just stating that it seems to be completely unnecessary, confusing, and not a
good idea to do so. :-) Seriously, why are we doing this? – __proto__ is an
accessor, it's much simpler to just spec it as such, why are we trying to set
up hoops for ourselves to jump through to avoid doing so?
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Jan 29, 2012, at 3:25 PM, Gavin Barraclough wrote: > On Jan 29, 2012, at 11:36 AM, Allen Wirfs-Brock wrote: >> Other standard properties that have accessor like characteristics but look >> like data properties: >> >> array element properties >> array length property >> string character element properties >> argument object elements >> the "caller" property of function objects (see 15.3.5.4) > > The special handling for setting array length and and numeric properties fits > well with the spec's existing division of labour between the [[Put]] and > [[DefineOwnProperty]] algorithms, and is well encapsulated. [[Put]] provides > a simple set of rules for determining whether a [[DefineOwnProperty]] will be > called on the base of the access, or whether a setter will be called on the > prototype chain. The 'magic' here is constrained to certain objects > overriding the [[DefineOwnProperty]] trap (e.g. 15.4.5.1). > > It seems that any 'magic' to make __proto__ work in the proposed fashion > could not be constrained to a [[DefineOwnProperty]] trap for the Object > prototype, since if __proto__ is a data descriptor [[Put]] will trigger > [[DefineOwnProperty]] trap on the base of the access. Any special handling > would either need to also rework [[Put]] to cause the special __proto__ trap > to be triggered, or would need to be worked into Objects's > [[DefineOwnProperty]] (8.12.9). Any special handling in 8.12.9 would need to > be non-trivial, since setting an object's __proto__ property would mean > re-inspecting the prototype chain to see whether the nearest __proto__ was > the magic data descriptor. Either way seems unnecessarily complicated, and > much less well encapsulated than Array's special handling of > [[DefineOwnProperty]]. There are no rules that constrain [[Put]] in this manner you are suggesting. > > I just don't see why we would want to muddy up some core mechanisms of the > object model, making them more difficult for users of the language to > understand, for the non-benefit of making __proto__ appear to be something > that it isn't. It just seems like a bad idea wrapped in a bad idea to me. Well, arguably the existence of __proto__ is what muddys up some of the core semantics of the object model. I would specify it as a modification to the normal [[Get]] and [[Put]] behavior that special cases on the property key value "__proto__". That special case (of [[Put]]) would not call [[DefineOwnPropertry]]. It would include check the prototype chain but that is part of the proposed semantics. This seems like a perfectly reasonable way to specify this. As __proto__ does indeed affect the property access semantics for every object. Of course, I'm only talking specification. How you accomplish it in your implementation is up to you. There are other, alternatives. If we were willing to only define obj.__proto__ and exclude obj["__proto__"] I could specify it in 11.2.1 as a special case semantics of dot property access notation and have to extend any of the internal methods. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Jan 29, 2012, at 11:36 AM, Allen Wirfs-Brock wrote: > Other standard properties that have accessor like characteristics but look > like data properties: > > array element properties > array length property > string character element properties > argument object elements > the "caller" property of function objects (see 15.3.5.4) The special handling for setting array length and and numeric properties fits well with the spec's existing division of labour between the [[Put]] and [[DefineOwnProperty]] algorithms, and is well encapsulated. [[Put]] provides a simple set of rules for determining whether a [[DefineOwnProperty]] will be called on the base of the access, or whether a setter will be called on the prototype chain. The 'magic' here is constrained to certain objects overriding the [[DefineOwnProperty]] trap (e.g. 15.4.5.1). It seems that any 'magic' to make __proto__ work in the proposed fashion could not be constrained to a [[DefineOwnProperty]] trap for the Object prototype, since if __proto__ is a data descriptor [[Put]] will trigger [[DefineOwnProperty]] trap on the base of the access. Any special handling would either need to also rework [[Put]] to cause the special __proto__ trap to be triggered, or would need to be worked into Objects's [[DefineOwnProperty]] (8.12.9). Any special handling in 8.12.9 would need to be non-trivial, since setting an object's __proto__ property would mean re-inspecting the prototype chain to see whether the nearest __proto__ was the magic data descriptor. Either way seems unnecessarily complicated, and much less well encapsulated than Array's special handling of [[DefineOwnProperty]]. I just don't see why we would want to muddy up some core mechanisms of the object model, making them more difficult for users of the language to understand, for the non-benefit of making __proto__ appear to be something that it isn't. It just seems like a bad idea wrapped in a bad idea to me. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
On Sun, Jan 29, 2012 at 10:09 PM, Xavier MONTILLET wrote: > 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 cyclic references, you still have to do > something about it. Ignoring the properties will probably make devs > wonder why this property isn't cloned and throwing an error is, IMHO, > no the kind of behavior you want. Ah I'm sorry, you're right. Cyclic refs do have to be taken care of otherwise you'll end up in an endless loop. I have no opinion on the matter though and would suggest it to be tackled the way JSON.stringify does it now. Whatever way that might be. Imho the cloned object (for json.parse) should not have any refs though. - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
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 cyclic references, you still have to do something about it. Ignoring the properties will probably make devs wonder why this property isn't cloned and throwing an error is, IMHO, no the kind of behavior you want. On Sun, Jan 29, 2012 at 9:56 PM, Peter van der Zee wrote: > On Sun, Jan 29, 2012 at 7:50 PM, Xavier MONTILLET > 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, especially nothing invisible (like references, object > instances or attributes). You can save that fancy stuff for > Object.clone :) > > - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
On Sun, Jan 29, 2012 at 7:50 PM, Xavier MONTILLET 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, especially nothing invisible (like references, object instances or attributes). You can save that fancy stuff for Object.clone :) - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: (How) does proto operator distiguish between function and non-function in LHS?
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
>
>let superclass = function () {};
>//define a constructor method
>superclass.new = function () {return (new this()).initialize()};
>//define a instance method
>superclass.prototype.initialize = function () {return this};
>let subclass = superclass <| function () {};
>...
>
> Question: When RHS is function expression, does it distinguish if LHS is
> function to select one of the (different) behaviours from above?
from the proposal: "If the LHS operand has a property named prototype and the
RHS operand is a function expression then the [[Prototype]] of the function
object is set to the LHS object and the prototype property of the new function
is set to a new object whose [[Prototype]] is the value of the LHS’s prototype
property. Here’s a picture of what happens in this case: function "subclassing"
UML diagram"
In other words, it uses the value of .prototype to set the [[Prototype]]
of the new prototype object. If no such property exists, [[Prototype]] of the
prototype is set to its default value.
In all likelihood you would want EnhancedFunctionPrototype to be defined
similarly to this example from
(https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp0.js
) of doing something different:
//define a non constructible superclass that provides some
Smalltalk-like conventions
const AbstractClass = Function.prototype <| {
subclassResponsibility() {throw new Error(this.name+" did not
implemented an abstract method")},
shouldNotImplement() {throw new Error(this.name+" should not
implemented by "+this.name)},
name: "AbstractClass",
prototype: Object.prototype <|{
get class() {return this.constructor},
error(message) {throw new Error(message)},
subclassResponsibility() {return
this.class.subclassResponsibility()},
shouldNotImplement() {return this.class.shouldNotImplement()},
errorSubscriptBounds(index) {this.error("subscript is out of
bounds: "+index)}
}
};
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: "Static" inheritance of builtins
On Jan 28, 2012, at 12:54 PM, Herby Vojčík wrote:
> Hello,
>
> in ES, inheritance between "classes" was in fact only inheritance between
> their prototypes; the constructor functions always inherited from
> Function.prototype directly.
>
> Now, <| operator defines that
> Fun <| function SubFun (...) { ... }
> not only does parallel hierarchy so that
> SubFun.prototype.[[Prototype]] === Fun.prototype, but also
> SubFun.[[Prototype]] === Fun.
> So constructor functions ultimately descend from Function.prototype, but it
> may be indirectly. "Subclasses" themselves also inherit "static" properites
> from their superclass.
>
> Would it break things if this would be true for builtins, as well? So that
> (for example, not citing all):
It would certainly be observable. Whether is would actually breaking anything
can only be speculated at this point until somebody tries it in a widely used
implementation. My speculation is that no breakage would occur. Is this
important enough to try?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
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 - in JSC I'm pretty sure it's going to be faster and cleaner to implement > this as a regular accessor property. > > Now, it would certainly be possible to add a mechanism to allow this accessor > to masquerade itself as a data property, but it just seems too magical and > unnecessarily weird to do so. It behaves like an accessor, so it should look > like one. Other standard properties that have accessor like characteristics but look like data properties: array element properties array length property string character element properties argument object elements the "caller" property of function objects (see 15.3.5.4) > > cheers, > G. > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms "native" and "host"
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 laden term for "outside the usual realm of expectations." Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms "native" and "host"
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 language level semantics defined by the ECMAScript specification include the existence and specified behavor of "internal properties". It does not mean "application level" semantics such as the values of object properties or the actions performed by function objects when called. Other terms that may be useful: Standard Object - An ECMAScript object whose application level semantics are defined by the ECMAScript specification Built-in Object - an object that is provided by the ECMAScript implementation. A built-in object could be either an ECMAScript Object or a Foreign Object ECMAScript Function - an ECMAScript Object that has a [[Call]] internal property. Foreign Function - a Foreign Object that has a [[Call]] internal property ECMAScript Code Function - an ECMAScript Function whose application level semantics are defined using ECMAScript code ECMAScript Foreign Code Function - an ECMAScript Function whose application level semantics are defined in some manner other than with ECMAScript code Platform Object - An object that is provided by the environment that hosts the ECMAScript implementation. A Platform Object could be either an ECMAScript Object or a Foreign Object. (However, from a specification perspective I don't see why this is really any different from a Built-in Object as the ES implementation would have to provide the mechanism that enabled a hosting platform to expose such objects and hence they would appear to be "built-in") Note that objects that are implemented using Proxies are still ECMAScript Objects because the primitive semantics of proxies are defined by the ECMAScript specification. It may be useful to use On Jan 29, 2012, at 10:19 AM, Wes Garland wrote: > On 28 January 2012 22:51, Mark S. Miller 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 Node > hosting environment. If so, these are *not* host objects. > > I'm another person confused by the difference between host objects, native > objects, and objects like "Math". Given that I haved worked trying to define > the CommonJS host environment and that I write a lot of JS objects in C with > SpiderMonkey, you'd think I would know the difference, but I don't. At least > now I know I don't. I used to think I did, and that made reading the spec > less useful. > > I think the least confusing way forward may be to drop the terms "host > object" and "native object" completely from ES6. This isn't the first time > that this list has spent many email thread time confusing "host objects" with > "native objects provided by the host". By itself, this would suggest that the > right terminology is "native" and "non-native". > > In my opinion, we need terminology describing objects which are provided by > the host environment, and those which aren't. The language of implementation > is completely irrelevant here. Platform Object > > In GPSEE, we have CommonJS modules where exports can be functions implemented > in JS or C -- in fact, we purposefully prototype in JS and then write C > versions of "hot" library functions once code is in production. Assuming that standard [[Call]] semantics are use: Platform ECMAScript Function which if implemented in ECMAScript is also a Platform ECMAScript Code Function > > Rhino embeddings can do similar things, implementing some methods in JS and > others in Java. In this case, is a Java function native? Such Java implemented functions are ECMAScript Functions that are also ECMAScript Foreign Code Functions > > Here's something even funnier -- if you use Object.prototype.bind in > SpiderMonkey (Firefox 9) on a function written in JS userland and then call > .toSource() on the result, it reports that the function is native! > > *head exploding* > > Wes > > -- > Wesley W. Garland > Director, Product Development > PageMail, Inc. > +1 613 542 2787 x 102 > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
With your last two implementations, you don't keep cyclic references.
On Sun, Jan 29, 2012 at 7:39 PM, Peter van der Zee wrote:
> On Sun, Jan 29, 2012 at 7:23 PM, David Bruant 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, or define them with null. You can also debate
> whether you want to treat objects that don't directly inherit from
> Object as alien (right now that doesn't seem to be the case in Chrome
> at least.
>
> JSON.clone({foo:5}) -> {foo:5}
>
> These are the cases I could (easily) see debatable...
>
> JSON.clone({foo:function(){}}) -> {foo:null} or {}
> function F(){}
> JSON.clone({foo:new F}) -> {foo:{}} or {foo:null} or {}
> var f = new F;
> f.x = 5;
> JSON.clone({foo:f}) -> {foo:{x:5}} or {foo:null} or {}
> F.prototype.x = 5;
> JSON.clone({foo:new F}) -> {foo:{x:5}} or {foo:{}} or {foo:null} or {}
>
> But I guess keeping the same behavior as JSON.stringify for a
> JSON.clone method might be best to keep things consistent. So
> something like Mark's last suggestion, to make the whole thing
> customizable.
>
> - peter
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
On Sun, Jan 29, 2012 at 7:23 PM, David Bruant 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, or define them with null. You can also debate
whether you want to treat objects that don't directly inherit from
Object as alien (right now that doesn't seem to be the case in Chrome
at least.
JSON.clone({foo:5}) -> {foo:5}
These are the cases I could (easily) see debatable...
JSON.clone({foo:function(){}}) -> {foo:null} or {}
function F(){}
JSON.clone({foo:new F}) -> {foo:{}} or {foo:null} or {}
var f = new F;
f.x = 5;
JSON.clone({foo:f}) -> {foo:{x:5}} or {foo:null} or {}
F.prototype.x = 5;
JSON.clone({foo:new F}) -> {foo:{x:5}} or {foo:{}} or {foo:null} or {}
But I guess keeping the same behavior as JSON.stringify for a
JSON.clone method might be best to keep things consistent. So
something like Mark's last suggestion, to make the whole thing
customizable.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
On Sun, Jan 29, 2012 at 1:23 PM, David Bruant 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 JSON.parse(JSON.stringify(o, opt_replacer), opt_reviver);
};
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
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 object, create new object and copy
> all properties with the same restrictions as before.
>
> I suppose another discussion is whether you'd want/need to copy
> property attributes as well. For me, for at least JSON.clone, I would
> be happy with just a clone of the primitive value of a property.
>
> In other words, I think a JSON.clone would work as if the structure
> was first serialized to a string. The serialization would drop any
> value or property that's not primitive, object or array. Objects and
> arrays are serialized to [] and {} notation. For arrays, only index
> properties are copied (so not even length or other properties). The
> resulting string would then be deserialized by JSON.parse. Of course
> the serialization doesn't need to happen internally, but I think hope
> that makes it clear what I mean (drops all weird stuff from structures
> like getters, setters and attributes).
Based on your description, it seems that the definition would be:
JSON.clone = function(o){
return JSON.parse(JSON.stringify(o));
}
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
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 displace html5's (IMO
horrible) "structured clone" operation, I would be much more positive about
rushing something sane through the standardization process. But we are
already too late to achieve that happy ending :(, and I see no other
adequate reason to rush this.
FWIW, I like the idea that any clone operation should be defined as
equivalent to JSON.parse(JSON.stringify(obj, ..), ..), and so I like your
suggestion of putting this on the JSON object. As for a more general
Object.clone, I agree with what I think is Allen's position: There is no
useful clone semantics/contract that applies in a uniform way across
different abstractions, and so it would be inappropriate to add such a
method to Object or Object.prototype. (Allen, apologies if I have
mischaracterized your position.)
On Sun, Jan 29, 2012 at 1:05 PM, Peter van der Zee wrote:
> 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 the same restrictions as before.
>
> I suppose another discussion is whether you'd want/need to copy
> property attributes as well. For me, for at least JSON.clone, I would
> be happy with just a clone of the primitive value of a property.
>
> In other words, I think a JSON.clone would work as if the structure
> was first serialized to a string. The serialization would drop any
> value or property that's not primitive, object or array. Objects and
> arrays are serialized to [] and {} notation. For arrays, only index
> properties are copied (so not even length or other properties). The
> resulting string would then be deserialized by JSON.parse. Of course
> the serialization doesn't need to happen internally, but I think hope
> that makes it clear what I mean (drops all weird stuff from structures
> like getters, setters and attributes).
>
> By putting such a method on JSON, you leave the way open for whatever
> clone should be on Object and still have an intuitive feeling for what
> JSON.clone would probably do (opposed to Object.clone).
>
> Cloning functions is a dangerous sport anyways due to closures, but I
> don't think anyone would expect JSON.clone to clone functions too.
>
> - peter
>
> On Tue, Jan 24, 2012 at 7:46 PM, Rick Waldron
> wrote:
> > non-recursive, deep clone by John-David Dalton:
> >
> >
> https://github.com/bestiejs/benchmark.js/blob/master/benchmark.js#L1001-1161
> >
> >
> > Rick
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms "native" and "host"
On 28 January 2012 22:51, Mark S. Miller 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 Node hosting environment. If so, these are *not* host objects. > I'm another person confused by the difference between host objects, native objects, and objects like "Math". Given that I haved worked trying to define the CommonJS host environment and that I write a lot of JS objects in C with SpiderMonkey, you'd think I would know the difference, but I don't. At least now I know I don't. I used to think I did, and that made reading the spec less useful. I think the least confusing way forward may be to drop the terms "host > object" and "native object" completely from ES6. This isn't the first time > that this list has spent many email thread time confusing "host objects" > with "native objects provided by the host". By itself, this would suggest > that the right terminology is "native" and "non-native". > In my opinion, we need terminology describing objects which are provided by the host environment, and those which aren't. The language of implementation is completely irrelevant here. In GPSEE, we have CommonJS modules where exports can be functions implemented in JS or C -- in fact, we purposefully prototype in JS and then write C versions of "hot" library functions once code is in production. Rhino embeddings can do similar things, implementing some methods in JS and others in Java. In this case, is a Java function native? Here's something even funnier -- if you use Object.prototype.bind in SpiderMonkey (Firefox 9) on a function written in JS userland and then call .toSource() on the result, it reports that the function is native! *head exploding* Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
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 the same restrictions as before.
I suppose another discussion is whether you'd want/need to copy
property attributes as well. For me, for at least JSON.clone, I would
be happy with just a clone of the primitive value of a property.
In other words, I think a JSON.clone would work as if the structure
was first serialized to a string. The serialization would drop any
value or property that's not primitive, object or array. Objects and
arrays are serialized to [] and {} notation. For arrays, only index
properties are copied (so not even length or other properties). The
resulting string would then be deserialized by JSON.parse. Of course
the serialization doesn't need to happen internally, but I think hope
that makes it clear what I mean (drops all weird stuff from structures
like getters, setters and attributes).
By putting such a method on JSON, you leave the way open for whatever
clone should be on Object and still have an intuitive feeling for what
JSON.clone would probably do (opposed to Object.clone).
Cloning functions is a dangerous sport anyways due to closures, but I
don't think anyone would expect JSON.clone to clone functions too.
- peter
On Tue, Jan 24, 2012 at 7:46 PM, Rick Waldron wrote:
> non-recursive, deep clone by John-David Dalton:
>
> https://github.com/bestiejs/benchmark.js/blob/master/benchmark.js#L1001-1161
>
>
> Rick
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
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 implement this as a regular accessor property. Now, it would certainly be possible to add a mechanism to allow this accessor to masquerade itself as a data property, but it just seems too magical and unnecessarily weird to do so. It behaves like an accessor, so it should look like one. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
