570568 - Calling JSPropertyOps against objects not of the corresponding class has bad human factors

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

Bug 565604, bug 548671 comment 2, and the required duplication of a prototype-chain walk to find the object with the actual right class are not intuitive, and it's easy to make a mistake.  It would be better if we did something else here, such that it wouldn't be the case that any class-specific C getter or setter didn't have to start with a prototype-walk to find a correctly-classed object.

This conceivably may want a new API.  Or it may want a change to existing APIs.  I haven't thought about the design space or what would be a desirable fix, just throwing this out in case people have ideas.

Comment 1

[Jason Orendorff [:jorendorff]]

How much of the trickiness is due to the API and how much is inherent? I don't know.

Note that per spec, JS getters and setters found on the prototype chain receive the initial object as |this|, just like JSPropertyOps. So if we were to change this, API users might just find the new behavior astonishing in a different way.

Comment 2

[Jeff Walden [:Waldo]]

Also bug 571014.

Comment 3

[Brendan Eich [:brendan]]

There's no free lunch, or least, there wasn't back in the C day. JS has type confusion inherent in getters and setters. They must check instance type (as must native functions) if they want to interpret private slots. Can C++ help?

Jorendorff long ago mentioned a road-not-taken, not only in SpiderMonkey but in ECMA-262 and all engines I know of: instead of using [[Class]]-specific [[Value]] internal properties or equivalent, all private data would be accessed by hidden names (a la the http://wiki.ecmascript.org/doku.php?id=strawman:names proposal). You'd still have to handle a no-such-property condition.

/be

Comment 4

[Jeff Walden [:Waldo]]

If a JS-defined getter or setter makes this mistake, it'll throw an exception but still have safe behavior.  The same is not true in C/C++.  To me this seems to warrant heightened scrutiny of the behavior, because the consequences of error are significantly worse, perhaps even to the point of making C/C++ getters and setters have different semantics from JS-defined ones.

A language extension with an increase in attack surface seems worse than the disease here, to me.

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #4)
> If a JS-defined getter or setter makes this mistake, it'll throw an exception
> but still have safe behavior.  The same is not true in C/C++.  To me this seems
> to warrant heightened scrutiny of the behavior, because the consequences of
> error are significantly worse, perhaps even to the point of making C/C++
> getters and setters have different semantics from JS-defined ones.

We're not going to do that, it will slow down accesses and break quickstubs and the general ability to optimize from JS to C functions.

Think about using the C++ type and template systems instead.

> A language extension with an increase in attack surface seems worse than the
> disease here, to me.

This is not a language extensions. It's an internal API.

/be