David Herman wrote:
On Aug 8, 2012, at 2:23 PM, Brendan Eich wrote:
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...
(Note: I did write the double-cited text above, in reply to Doug.)
With too many of these conversations about various "modify an object" operators, we've started from
"here's a thing let's talk about it" rather than "here's the problem we're trying to
solve."
I don't think that's fair. We have been talking about Object.extend, the
possible value of syntax for it, assign vs. define, all based on real
use-cases. The Caja experience shows that people do use = to shadow
prototype properties, when that can't work if the proto-prop is accessor
not data (this gives Caja its workaround). We're pretty
real-problem-based on this stuff.
The problem is that neither = nor Object.defineProperty can be used
succinctly and reliably to shadow or override.
:= is only the latest in a line of proposals for solutions.
Specifically, for there to be dedicated syntax, the bar is high to prove that
it pays for itself.
Agreed.
Every time we talk about an operator whose semantics is based off of defineProperty, I'm
skeptical that it's providing real programmer benefit, as opposed to sort of
"completing the set" of semantic operations with dedicated syntax.
Object.defineProperty is a fine thing to have, and I'm glad ES5 added it, but IMO it's a
lower-level reflection operation, not a common operation. Allen should correct me, but I
think he doesn't disagree, since he says:
And, := should not be thought of or become the common way to do assignment.
That should remain the job of =
(That double-cited text is not mine, however -- it is from Allen, in
reply to me to Doug -- but Allen is not on your To/cc list for some
reason...)
If it's not common, then that's a strong case against getting dedicated syntax.
That is a bit circular. I agree the bar should be high, but the need for
:= is masked by overuse of =, which is buggy as the Caja experience showed.
The deeper point: maybe it's too late to fix anything (for Caja, or on
balance). But Allen argues the future of JS is longer than its past.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
