strawman for the := operator

Matthew Robb matthewwrobb at
Thu Aug 9 10:52:29 PDT 2012

I'd first like to state that I am extremely interested in having some
construct for the described intention behind the := operator

Based on the discussion here what comes to mind would be having the
following instead

Object.assign(obj, {...});
same as

Object.define(obj, {...});
same as

Specific method names for the Object.* could be decided upon. Would also be
nice, following the above, to have the following

obj:prop = value;

On Thu, Aug 9, 2012 at 12:32 PM, Brendan Eich <brendan at> wrote:

> David Herman wrote:
>> On Aug 8, 2012, at 5:01 PM, Brendan Eich wrote:
>>  The problem is that neither = nor Object.defineProperty can be used
>>> succinctly and reliably to shadow or override.
>> OK, that's the real problem, thanks for making it clear -- sorry if I
>> missed it before.
> No problem. The "succinctly and reliably" conjunction is important, but
> it's not an argument for new syntax, by itself. I think we agree that an
> API such as Object.update would solve most of the problem, if not all
> ("succinctly"). Object.update could be polyfilled, to boot.
>  So then the question becomes: how common should it be, then? Are the use
>> cases it addresses common enough to warrant new syntax?
> It's hard to say for sure, but I find the class "statics" use-case
> compelling, since maximin classes don't have any declarative support for
> class-side properties.
>  Especially syntax that looks like a new variation on an existing thing.
>> ("Wait, which kind of assignment do I need to use here?")
> That does look like trouble, now that you and Doug point it out. We have
> spiraled around .{ and := but not .= -- would .= be better?
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list