Nicholas C. Zakas wrote:
On 5/29/2012 9:45 AM, Brendan Eich wrote:
Note that the modern DOM and WebIDL are being spec'ed so typical DOM
accessors are on prototypes, so you can't "fix" the bug by using
[[Put]] only when the property is "own".
There really is a difference between assigning and defining in JS.
Assigning runs setters, even inherited ones. Defining overrides or
shadows. EIBTI.
Once again, I'm not debating whether there is or isn't a difference,
just whether or not that difference is perceivable to regular developers.
I'm not only saying there should be a difference (because JSON theft
hole re-opens, at least for mustache; and we want mustache and object
literal semantics to match for the same given syntax), but that regular
developers need to know what they're doing. This is true in JS today if
a "regular" developer ever needs to shadow or override rather than assign.
My theory is that it is not, and so you'll end up with a lot of code
that looks like this:
var element = document.getElementById("myDiv");
element.{
innerHTML: "Hello world!",
className: "enabled"
};
I hear you, and having a choice means people can choose badly. This was
one reason why => succeeded at the price of cutting ->. It's not an
absolutely fatal objection, though. Three points:
1. First, don't people test? You say we'll end up with a lot of code
like that, but such code won't work as intended. Developers may "start
up" like that and learn, then change and adapt. Again, there's no
iron-clad theory governing practice here, and people are smart about
learning what works.
2. With => the default is fail-safer (lexical this) compared to ->
(dynamic this). Anyone wanting -> and using => by mistake has a bug but
it can be found via testing more readily than a dynamic-this bug. In
other words, we want the failure mode to be a more overt bug, if it
can't be an early error.
3. If we changed mustache to diverge from object literals, then
developers who refactor or otherwise end up needing to define not assign
will be out of luck. This is not obviously fatal either, but it counts
against implicit sometimes-assign-sometimes-define semantics, IMHO.
Going by the current definition, this code block would actually have
no effect because it would be defining new own properties rather than
assigning values to the existing prototype accessor properties.
Yes, and there would not be any "Hello world!" in the div's text
content, and wouldn't the developer see that and fix?
Again I hear a lot of "we'll end up with permanent bugs" objections
(same thing for => not ->) but these fears presume lack of testing for
the more overt failure than you'd "end up" with the other way (if we had
-> not => semantics; or here, if we have = not : when the property
exists in or own).
I cringe at the thought of how long it would take most developers to
figure out that it is the colon that's the problem. IMHO, This code
doesn't behave as expected.
What is the expectation based on? Object.extend in prototype? That is a
fair point, but that function copies properties by assignment.
/be
-N
/be
Thanks,
Nicholas
On 5/28/2012 2:27 PM, Allen Wirfs-Brock wrote:
On May 28, 2012, at 1:23 PM, Erik Arvidsson wrote:
On Mon, May 28, 2012 at 12:19 PM, Nicholas C. Zakas
<[email protected]> wrote:
Is it intentional that the first example uses colons between the
property
and value while all others use the equals sign?
Yes this is intentional. We discussed this a bit at the F2F meeting
and we came up with the proposal to use = for [[Put]] and : for
[[DefineOwnProperty]]. Having a way to do [[Put]] is important
because
it is common to want to trigger setters.
At added a clarification of this to the strawman....
For example:
class Monster {
set health(value) {
this.barColor = value< 10 ? 'red' : 'green';
this._health = value;
}
}
class GiantSpider extends Monster {
constructor() {
this.{
health = 100
}
}
}
If you use .{health: 100} then the setter would not be invoked and
the
object would not be in a correct state. This example might be a bit
contrived but using [[DefineOwnProperty]] is not the right answer
in a
lot of cases.
This is especially important for setting values of DOM node
properties which are generally implemented as accessor properties
(ie, getters/setters). That is why I used (thanks to dherman) a
DOM element in most of the example that use +.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
