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