An experiment using an object literal based class definitionpattern

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Aug 9 12:27:14 PDT 2011


On Aug 9, 2011, at 1:29 AM, Claus Reinke wrote:

>> .. the key extensions I used in the collections experiment are:
>> ..
>>  *  the <| operator -- defines the [[Prototype]] of a literal
>>  *  the .{ operator -- extends the LHS object with properties from an object literal
> 
> How do these two relate to (non-destructive) object extension operators
> [1]?  The syntax mentioned there would line up with array spreads:
> 
>   { properties , ...: obj }
>    // returns copy of obj, extended with properties

Currently, what is being specified for ES.next has [...obj] but not {...obj} or {... : obj}

obj.{a:1,b:2}

is equivalent to Object.defineProperties(obj,Object.getOwnPropertyDescriptors({a:1,b:2}))
while (if it existed)

{... : obj, a:1, b:2}

would presumably mean something like:
  Object.create(Object.prototype,Object.getOwnPropertyDescriptors(obj)).defineProperties(Object.getOwnPropertyDescriptors({a:1,b:2}))

> 
> If that is the same idea, then it is something I'd like to see [2]. Both
> syntax variations share the limitation to literal extension properties,
> the spread variation is more conventional and tends to be suitable
> for both construction and destructuring (also, one could write the
> extended object at the front or at the back), so it might be preferable?

I had missed [2] when it first came by, so thanks for pointing it out.  I generally agree that a complete set of compositional operations based upon copying seem useful.  But for now, it seems more like work for the future that we possibly could try to future proof for.

> 
> It seems that <| is merely a special case, aiming to avoid naming [[Prototype]], right?

It is probably valid to look at it that way, but it is also intended to be a concise way to directly specify the [[Prototype]] for various literal forms.

I have defined it to be a copying operation (even though because the RHS is always a literal an actual copy is not required) with the expectation that someday we would extend it to allow non-literal expressions on the RHS.  To do this, we would first need to define a semantics for shallow copy that deals with the various complexity of the language such including non-standard internal methods, host objects, proxies, etc.  Also, a good shallow copy frame really needs to have hooks (pre-copy, post-copy, etc.) to allow application level invariants to be managed. 


> 
> Claus
> 
> [1] http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#issues
> [2] https://mail.mozilla.org/pipermail/es-discuss/2011-June/015475.html



More information about the es-discuss mailing list