strawman for the := operator

Brendan Eich brendan at mozilla.org
Wed Aug 8 14:23:11 PDT 2012


Douglas Crockford wrote:
> I am not in favor of adding := to the language (as I am not in favor 
> of adding to the language generally), but if := is added, my practical 
> advice will be to always use := and never use =.

I hesitate to point this out, since it will convince you that := should 
not be added, but := is not a substitute for =!

As proposed at 
http://wiki.ecmascript.org/doku.php?id=strawman:define_properties_operator 
by Allen, both the LHS and RHS of := are ToObject-converted (only null 
and undefined throw) and the result of so converting the RHS is 
inspected for own properties which are copied into the LHS as if by ES5 
meta-object APIs that preserve accessors (vs. data props), attributes, etc.

So you can't change x = 42 into x := 42. First, x must not denote null 
or undefined. Second, ToObject(42) has no own properties so nothing new 
is defined on x. Third, if x were a primitive boolean, number, or 
string, I take it from Allen's proposal that a throwaway Boolean, 
Number, or String wrapper would be created and (if the RHS dictates) 
extended.

> We will probably see better performance with := since it doesn't have 
> to slide down the proto chain to see if the assignment works. 

This isn't a problem in at least some modern JITs.

> And I like stepping away from ='s visual ambiguity, looking too much 
> like an equality operator. It could be argued that = is still needed 
> for respecting some kinds of inherited stuff, but it could also be 
> argued that those kinds of inherited stuff are just weird edge cases 
> that can now be conveniently and efficiently avoided.

You mean every single DOM property specified by a WebIDL attribute?

> So if we do add :=, we should allow it to work on variables too, for 
> consistency. 

See above -- := is not a drop-in replacement for =. Think of it more 
like the .{ proposal, which had at one point suggested alternative 
syntax: .= (with an object literal to the right, but the latest proposal 
relaxes that to be any expression given to ToObject).

/be


More information about the es-discuss mailing list