Closed Bug 640724 Opened 13 years ago Closed 12 years ago

Data props implemented by getter/setter behave weird

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: evilpie, Unassigned)

Details

When a property access propagates from some object to another via [[Prototype]] the getters are invoked with the orginal object, which won't be the same type as those expected by these getters.

Example:
>var s = new String('xxx');
>var o = {__proto__: s};
>print(o.s);
This throws, because in the end we try to call String.prototype.toString on o

Even more weird, but i will probably fix this in Bug 640593.
>var f = function test () {};
>var o = {__proto__: f};
>print(o.name);
undefined, because we don't walk the [[Prototype]] for "name" in fun_getProperty.
Assignee: nobody → general
Component: jemalloc → JavaScript Engine
QA Contact: jemalloc → general
That's the right behavior, no?  For a prop with a getter/setter that's found on the proto chain the |this| object passed to the getter/setter is the object the original prop lookup happened on.  That's how it's supposed to work!
We implement this as getter/setter, but actually they are data props. So |this| is not important per spec.
I assume you meant print(o) in the first example?

Converting name and some of the other Function ops-based properties into there-from-birth instance properties, as done for RegExp in bug 640072, would fix this.  I see other issues (potential and real) doing that right now, but with some other changes it might be possible eventually.
oh i meant o.length
Depends on: 640503
I can't reproduce the two issues in the original report.
Status: NEW → RESOLVED
Closed: 12 years ago
No longer depends on: 640503
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.