A read/write __proto__ that can vanish
brendan at mozilla.org
Wed Jul 16 11:41:19 PDT 2008
On Jul 16, 2008, at 10:29 AM, Ingvar von Schoultz wrote:
> Some people yearn hotly for __proto__, preferrably writable if
> at all possible, while others point to problems with security
> and software privacy.
I wrote recently that __proto__ should be viewed as call/cc without
macros for common use-case (and average users) -- too sharp and low-
level a tool for a language like JS.
> I get the impression that this could be solved by adding a fourth
> flag among the property flags Enumerable, Writable and Flexible.
> There might be a flag called Visible, so you could make __proto__
> apparently vanish by setting Visible to false.
There's no point in Visible if the property could be deleted
altogether. What would be the difference? Note that a proto or
__proto__ property reflecting [[Prototype]] is *not* the same as the
internal [[Prototype]] property, which would always be "visible" in
the sense of checked by [[Get]], [[Put]], etc.
We should not add property attributes that can mutate lightly. The
motivation for __proto__ is suspect (I argue, base on our experience
-- and I perpetrated __proto__ a long time ago). The need for Visible
is non-existent IMHO, while the costs and ramifications of another
single-bit attribute, one that causes the property to appear to be
deleted, are undesirable.
Visibility control over names is an important topic, but it can't be
served by a single-bit attribute. ES4 as proposed has namespaces to
serve (among other use-cases) the cheap and easily expressed private
members use-case. That's not this __proto__ case, which anyway
depends on a suspect predicate (the "need" for __proto__). Better to
settle the predicate issue first, and avoid adding general mechanism
More information about the Es4-discuss