July 25, 2012 - TC39 Meeting Notes

Brendan Eich 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 
> function.

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).

/be

> 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
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list