prototype for operator proposal for review

Allen Wirfs-Brock allen at wirfs-brock.com
Tue May 17 23:02:14 PDT 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110517/3be50dfe/attachment.html>


More information about the es-discuss mailing list