W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Violations of internal method invariants?

From: Jason Orendorff <jason.orendorff@gmail.com>
Date: Thu, 31 Jul 2014 08:43:51 -0500
Message-ID: <CAPh8+ZpRTcS4T+rUNJP8Sopa73DLtx9TK5rmLPoQDPN=9iz4Zw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Tom Van Cutsem <tomvc.be@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Requiring a single namespace, such that adding an input and then removing it
> would make a previous property with the same name as the input go away,
> would actually be fairly annoying performance-wise, I suspect.

Really? There are web pages that add inputs to forms in a tight loop?

> In any case, I would be very interested in figuring out what sane
> (sane-enough?) behavior UAs are willing to converge on here so we can
> actually spec it....  If anyone has suggestions for what that behavior
> should be, I'd love to hear them.

Right Thing: I think [[PreventExtensions]] on these objects should
always return false. I think [[DefineProperty]] on these objects
should return false if Desc.[[Configurable]] is false or if it's
missing and would default to false. That'll cause Object.freeze(form)
and Object.defineProperty(form, "x", {configurable: false}) to throw a
TypeError. Seems legit.

Alternative: Specify what Gecko does. Make non-configurable properties
on these objects shadow even the named getter.

At the moment, I don't see anything else that would preserve the
object invariants.

-j
Received on Thursday, 31 July 2014 13:44:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC