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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
