A read/write __proto__ that can vanish

[Brendan Eich]

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

/be