July 25, 2012 - TC39 Meeting Notes
brendan at mozilla.org
Sat Jul 28 08:03:58 PDT 2012
Brandon Benvie wrote:
> It seems like you're indicating that changing a property to a value,
> presumably a primitive, is somehow different from setting it to a
I read Herby as arguing that overriding a prototype property is
low-level, so must use low-level Object.defineProperty. Due to setters,
assignment is in contrast high-level: if you assign to a try to create
an own property, but there's a prototype setter with same name, the
setter will be invoked.
I agree with Herby.
The problem for Mark Miller based on SES, not necessarily for David (who
could change his code), is that extant JS libraries predate ES5 and use
assignment. Perhaps they predate setters in the wild (first in
SpiderMonkey over 12 years ago), or the author didn't think of setters.
Mark's SES workaround actually relies on setters not being overridden by
assignment: before freezing common prototype objects that might
(according to a clever heuristic) pose a problem, SES enumerates
properties on them and replaces each with an accessor whose setter
intentionally shadows (since setters receive the target |this|).
Anyway, I don't think function-valued vs. non-function-valued is the
issue. It's override-of-data-property (vs. non-override-of-accessor).
> Regardless of anything else, that's not true even in the way you mean
> it because a function can have a thunk that contains state and
> accomplishes the same thing as setting primitive data type. It just
> can almost be used for other non-data things too like methods. There's
> no way to differentiate from a naive standpoint though.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss