Object.defineProperty buggy

Jan 12, 2011 at 6:42 AM

They are (at least) two problems with the current defineProperty implementation :

- The default value for 'wittable' and 'configurable' are set to true, where the spec says it should be false. Object.defineProperty(y,"a",{value:4}) should declare a non-configurable read-only property.
- When we're updating a data property (for example, to set the writtable attribute from true to false in order to freeze the object) using defineProperty, the current value is lost and undefined is used instead.

This engine appears to be great, that fact kept apart ;-)
Nice work.

Coordinator
Jan 12, 2011 at 8:21 AM

> Object.defineProperty(y,"a",{value:4}) should declare a non-configurable read-only property.

As indeed it does...

> When we're updating a data property (for example, to set the writtable attribute from true to false in order to freeze the object) using defineProperty, the current value is lost and undefined is used instead.

Yes, agreed.  I believe this is the correct behavior - table 7 of section 8.6.1 of the spec implies that [[Value]] is undefined if it is not specified.  This is symmetrical with the way the other properties work (i.e. they default to a fixed value and not the current state of the property).

If you want to freeze an object why don't you use Object.freeze()?  Alternatively, you can do this: Object.defineProperty(y, "a", {value: y["a"]}).

Jan 12, 2011 at 10:06 AM
I don’t agree with you explaination about property updates. The relevant part of the spec is :
P42, 8.9.12.9, Step 12 :
For each attribute field of Desc that is present, set the correspondingly named attribute of the property named P of object O to the value of the field.
It does mean that the current property’ value is kept if the Desc object has no ‘value’ property, and only modified attributes are updated. On my test case, IE9 & FireFox 4 both performs the same way : they conserve the current value, and just modify the [[Writtable]] field so I’m pretty confident I’m right here.
Jan 12, 2011 at 10:13 AM

I've found another issue. This time with Object.keys.

> Object.keys(this)
>>> console,y

This should contains Math since the Math object is accessible and defined in this (this.Math return the Math object).

This issue occurs with many platform object (Objects.keys(Object) returns no value).

Coordinator
Jan 12, 2011 at 10:28 AM

> I don’t agree with you explaination about property updates

Hmm, I think you might be right.  Certainly that sentance makes no sense if my interpretation is correct.  That means Chrome 8 is also wrong, since it does the same thing as Jurassic.  Drat :-)

> I've found another issue. This time with Object.keys

Math is not returned by Object.keys because Math is not enumerable and Object.keys only returns enumerable properties.  This is specified in section 15.1 and section 15.2.3.14.

Jan 12, 2011 at 10:45 AM

Hum, I didn't notice you've put Math as a non-enumerable property. Good point.

Still, there's a 'problem' with the Object.prototype.toString function. Please run the following test case :

t={valueOf: function() { return 't'; }}
""+t // should return "t" and not "[object Object]"

(In case you wonder way I've so many tests in my mind, it's because I someday had planned to implement a JScript engine in .NET, so I had a list of things I should care of in my mind :D)

Coordinator
Jan 12, 2011 at 11:04 AM

> Still, there's a 'problem' with the Object.prototype.toString function.  Please run the following teest case:

The bug was not in Object.prototype.toString but with the addition operator itself.  Good catch!

Coordinator
Jan 12, 2011 at 11:07 AM

I have checked in fixes for the Object.defineProperty bug and the addition operator bug.

Coordinator
Jan 12, 2011 at 11:25 AM

I uploaded a new version of the silverlight console on the jurassic homepage - so you can see for yourself that the bugs are fixed.

Jan 12, 2011 at 7:49 PM
<!--BeginFragment-->

Yay, you fixed it online very quickly. Nice ;-)

BTW, does your implementation works with the [[ParameterMap]] logic implemented for the Arguments Object ? I did some testing on the arguments Object and it seems it didn't work, even in non-strict mode. But I'm not sure I clearly understood how it should work from the spec.

<!--EndFragment-->
Jan 12, 2011 at 7:49 PM

At least arguments.callee didn't work (not important, though, as it's not very useful)

Coordinator
Jan 12, 2011 at 8:57 PM

> BTW, does you implementation works with the [[ParameterMap]] logic implemented for the Arguments Object ?

Yes, it should work.  For example, this code:

function ParameterMapTest(a) {
  arguments[0] = 4;
  delete arguments[0];
  arguments[0] = 5;
  return a;
}
ParameterMapTest(3)

returns 4.

> At least arguments.callee didn't work (not important, though, as it's not very useful)

It should work.  Do you have a test case?

Jan 13, 2011 at 5:55 AM
I thought arguments.a should return 3 but it don't seem to be the case in
IE9, so I may be wrong.