On Jun 17, 2009, at 7:34 PM, Mark S. Miller wrote:
> On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs@...>
>> On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
>>> I suspect we'll see some de-facto stuff come out of one or two
>>> vendors who
>>> aren't active in TC39 (Apple, Google V8).
>>> Google is quite active in TC39. Google's representatives to TC39
>>> (including me) are now in close coordination with our v8 team.
>>> However, v8
>>> remains committed to following WebKit. Fortunately, AFAIK, WebKit
>>> has not
>>> yet taken any stance on whether [[Prototype]] will be mutable in
>>> their ES5
>>> implementation. Maciej?
>> Your phrasing of the question strikes me as odd, because changing
>> of de facto extensions like this seems orthogonal to supporting a new
>> version of the spec. If getting rid of or restricting mutable
>> turns out to be feasible and a good idea, then we would not tie it to
>> implementation timeline for ES5 features.
> The tie to ES5 is that ES5 introduces the notion of frozen objects.
> with ES5/Strict function's encapsulation being protected even from
> non-strict code, this enables the creation of tamper-proof objects.
> But only
> if frozen objects cannot have their [[Prototype]] property changed
> out from
> under them.
The fact that ES5 has the provision for frozen objects doesn't mean
that all (or substantially most) objects in the system will be frozen.
I think it's worth considering how useful killing __proto__ will be
should the Harmony class system NOT freeze objects by default. I
suspect not very.
>> As to the substantive issue: mutable __proto__ is something we
>> would prefer
>> not to have, but we are concerned about the compatibility issues.
>> We look
>> forward to hearing about Mozilla's experience with changing it.
> In case this experiment does run into problems, what do you think
> Allen's proposed restriction: "That [[Prototype]] is guaranteed not to
> change on an object for which [[Extensible]] is false."? This takes
> care of
> the security issue I'm concerned about and won't break any old code.
>> Personally, I think leaving "distasteful" but cross-browser
>> features like
>> this out of the spec in the hopes that they will wither away from
>> neglect is
>> a poor approach. If browsers feel pressured to implement such
>> extensions for
>> Web compatibility then we are not doing anyone any favors by
>> leaving them in
>> the domain of mutual reverse-engineering. I would prefer to see such
>> features explicitly specified (with suitable restrictions) or
>> forbidden, and perhaps explicitly deprecate them with the plan for
>> limits or outright removal in future versions of the spec. But it
>> seems too
>> late to make big changes in this regard for ES5.
>> Maybe in the next version.
> +100. An exhaustive list of such features should at least be
> enumerated in a
> non-normative appendix. If they had, it wouldn't have taken us so
> long to
> catch the mutable [[Prototype]] and F.caller issues. What other such
> might we have missed?
> In a closely related matter, we also need to tighten the Chapter 16
> exemptions, as the presence of these exemptions precludes *any* sound
> of what
> such tighter language should say. Suggestions appreciated.
> es-discuss mailing list
> es-discuss@... > https://mail.mozilla.org/listinfo/es-discuss