strawman for the := operator

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Aug 9 11:01:28 PDT 2012


On Aug 9, 2012, at 9:32 AM, Brendan Eich 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.

I think succinctness is a very important considerations in this case. One of the root problems is that it is just too darn easy to say = rather than Object.defineProperty or Object.update.  Even those of us who know better take the shortcut and use = whenever we think we can get away with it. 

I don't think any of the proposed procedural APIs are likely to change that habit.  I think := stands a change.  I'm pretty sure it would  change my behavior.

> 
>> 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?

Pushing devs to think "which kind of assignment do I need to use here?" and then acting appropriately is the whole point.  The similarity between = and := encourages this thinking.  Once a dev fully internalized the difference between property definitions and value assignment and which operator is associated with each concept they will seldom actually have to stop and think. 

I don't think that .= is a better alternative than := as it less suggestive "define".  I can imagine utility in having three = forms:

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"

allen





More information about the es-discuss mailing list