strawman for the := operator

Allen Wirfs-Brock allen at
Thu Aug 9 16:05:27 PDT 2012

On Aug 9, 2012, at 1:49 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> targetObj.prop = value         //assign a value to a single property
>> targetObj .= sourceObj        //assign values from sourceObj properties to corresponding targetObj properties
>> targetObj := sourceObj        //define properties on targetObj that clone properties of sourceObj
>> If we only defined := now, we could still define .= in the future.  If we define .= now to mean "define property" we don't have a good future alternative for  "assign multiple property values"
> But .= does not connote "assign" rather than "define". You make the case that := suggests "define" by reference to the : separating property name from value in object literals, and that's helpful. There's no dot analog for colon, however.
> Indeed if sourceObj is an object literal, we'd have, e.g.,
> targetObj .= {prop1: val1, prop2: val2}
> and at least as many colons as dots.

Well, strictly speaking the object literal that is the RHS of the above example is defining properties on a new object and those the properties of that object are then assigned to corresponding properties of the LHS object.

Regardless, the associations between the symbols and the semantics don't have to be perfect they just have to be close enough to have some mnemonic value. 

> The more I think about this, the more I doubt we can help people decide between assignment and definition just by giving both short syntax. The requirement to define rather than assign is independent of syntax at the redefinition point, inherent in the object model being used.
> Further, assignment via = will remain the most common case, and the source of bugs to reduce by documentation and education, no matter the syntax of the fix. In teaching people how to make the fix or avoid the bug, you're right that short syntax can help, but it's not clear how much. As Dave points out, that depends on how often the need for define-not-assign arises.

I don't think the new syntax would directly help them understand their intention.  That is something they need to understand, independent of syntax.  But the existence of both = and :=   may encourage developing this level of understanding; simply by making the choice available.

The primarly purpose of new syntax shouldn't be pedagogical.  Rather it should help and encourage good programmers to write good code. I want programmer who know they are defining a property to be able to easily express that intent rather than lazily using = even though they know  better.  I'm pretty sure I would always use :={...} over = in those situations.  I not so sure that I would be disciplined enough to always use Object.update(...) rather than  = in such situations.

> I fear we're missing the opportunity to get into Object.update by getting stuck on syntax. The ES5 APIs are too verbose but that doesn't mean something like Object.extend should be left to libraries and not built in, as JSON and Function.prototype.bind were in ES5.

I certainly don't have any objection to have the procedural forms.  Personally, I think Object.define and Object.assign would be a good names for the two concepts we have been talking about.  Having such functions would actually make it easier to explain corresponding syntactic forms.
Object.define(Point, {
   fromPolar(rho,theta) {
      return new this(rho*Math.cos(theta), rho*Math.sin(theta))
is not as readable or writable as:
Point := {
   fromPolar(rho,theta) {
      return new this(rho*Math.cos(theta), rho*Math.sin(theta))
(note how "Point" gets visually lost in the procedural form. The eye focuses on "Object.define" rather than the more important "Point")

If := wasn't available I'd certainly want to have the procedural form available.  All names are bikeshedable...


> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list