Closed
Bug 640724
Opened 13 years ago
Closed 12 years ago
Data props implemented by getter/setter behave weird
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
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.
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → general
Component: jemalloc → JavaScript Engine
QA Contact: jemalloc → general
Comment 1•13 years ago
|
||
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!
Reporter | ||
Comment 2•13 years ago
|
||
We implement this as getter/setter, but actually they are data props. So |this| is not important per spec.
Comment 3•13 years ago
|
||
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.
Reporter | ||
Comment 4•13 years ago
|
||
oh i meant o.length
Reporter | ||
Comment 5•12 years ago
|
||
I can't reproduce the two issues in the original report.
You need to log in
before you can comment on or make changes to this bug.
Description
•