Discuss
  • A read/write __proto__ that can vanish

A read/write __proto__ that can vanish

# Ingvar von Schoultz (17 years ago)

Some people yearn hotly for proto, preferrably writable if at all possible, while others point to problems with security and software privacy.

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.

As an added bonus, this solution would let code hide the prototype property on constructors if desired.

Personally I'd love to see it defined in such a way that I could set prototype inheritance in a simple, straightforward way at the beginning of a constructor function:

 function $MyConstructor()
 {	this.proto = MySuperInstance;
     // Here you can hide proto if desired.
     ...
 }

If a visible proto is standardized, the name should be proto, not proto, in my opinion. The underscores indicate nonstandard.

# Brendan Eich (17 years ago)

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.

# Allen Wirfs-Brock (17 years ago)

Personally, I don't that the internal [[Prototype]] "property" should reify as an actual property of the object. It's really a more fundamental aspect of "objectness" than regular properties. From that perspective, if you want to control access to it, it should probably be done as a flag on the object itself, much as the ES3.1 proposal does with the [[Extensible]] property.

# Waldemar Horwat (17 years ago)

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

Adding switches like this is making code too complicated and will result in plenty of arguments about whether a particular class should have the switch turned on or off. Often the classes you want to use will have it set the wrong way, leading to more balkanization of libraries. In the committee we've already spent too much time discussing which properties should be enumerable, dontDelete, etc., and we still get those wrong at times.

Waldemar
# Ingvar von Schoultz (17 years ago)

Brendan Eich wrote:

There's no point in Visible if the property could be deleted
altogether. What would be the difference?

Oops! Sorry! Lacking low-level insight I didn't think of that.

So my idea has no bearing at all on the inherent problems, much less solved them. Too bad.

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.

I think the only situation where I repeatedly feel a real, serious need for something like a writable proto is the one I showed. Specifying inheritance is too spread out and too intricate. Most of all I want the constructor to define its own inheritance, not some outside code. Having to set .prototype in an unrelated expression outside, with the constructor reduced to a powerless bystander, feels like I'm writing a goto. It's too unstructured.

Is your objection to proto similar to this? Is proto an inheritance goto? If that's the kind of problem it creates I agree that it doesn't belong in this language.

If that's the case, would a writable proto become well- structured if it could be accessed only from inside the constructor, and not by any other code? That's the only way I'd use it anyway.

I'd love to have constructors that could write to their [[Prototype]]. But if that isn't possible I'd be almost as happy if we simply had the option to set both the prototype and its constructor property in one compound statement:

 function $MyConstructor()
 prototype MySuperInstance
 {	...
 }

For me this would generally be the best arrangement, and I suppose it's the same for most people. Not having analyzed all the details, it /seems/ to me that the ideal would be that the above syntax lock and hide [[Prototype]], while a different syntax for exotic use would allow the constructor added freedom.