On May 17, 2011, at 9:49 PM, Luke Hoban wrote:
> If there were a more usable library variant of Object.create instead, it
> seems the new syntax here would not be as necessary.
>
> Instead of:
> var o = myProto <| {
> a: 0,
> b: function () {}
> }
>
> You could do:
> var o = Object.make(myProto, {
> a: 0,
> b: function () {}
> })
>
> A few more characters, but still addresses the major issue preventing wider
> Object.create usage (the use of property descriptors). A library solution
> also keeps the benefit of not needing new syntax, and being available to
> text/javascript. As noted in the strawman, similar functions on Array and
> Function could support the other scenarios described in the proposal.
That isn't really what this proposal is about, but it is what the
http://wiki.ecmascript.org/doku.php?id=strawman:concise_object_literal_extensions
proposal addresses.
The primary scenario is what some people call "subclassing" the various
built-in classes of objects that have special internal state and behavior. The
most important of these "classes" are Array, Function, and RegExp. Programmer
want to be able to create instances of these whose direct [[Prototype]] is
different from the default. (in most cases the desired prototype will inherit
from the default)
Specifying the prototype for an object literal is also a scenario but I
wouldn't necessarily say it is more important than the other.
>
> It seems the syntax is perhaps aiming to avoid needing to allocate an
> intermediate object – but I imagine engines could potentially do that for
> Object.make and friends as well if it was important for performance?
An implementation might try to optimize such functions as you describe, but
because both the global binding to the base object and the property binding of
the method are mutable you at least have to have a dynamic guard on any fast
path and still have to generate the code to create the arguments and do a
regular call if the guard fails. I made the same argument for Object.create
and I'm not aware of implementation that have yet to optimize it in this manner.
Another difference from the function approach is that the function can assume
it is being passed a new object or even any object of the kind it is expect.
The <| ooperator is syntactically required in the current proposal to have a
literal form as its right operand so both implementations and human code
readers can determine by examination what [[Class]] of object is being created.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
