591059 - ES5: Support read-only array lengths

Status: RESOLVED DUPLICATE of bug 858381

(Core :: JavaScript Engine, defect)

Description

[Jim Blandy :jimb]

According to ES5, it should be possible to make an array's 'length' property read-only.  Various functions on Array.prototype will then fail in interesting ways, revealing implementation details, and many laughs may be had all around.

However, we don't implement this yet; search for uses of JSMSG_DEFINE_ARRAY_LENGTH_UNSUPPORTED.

Comment 1

[Jim Blandy :jimb]

Rob, do you think this should block?  It's pretty obscure.

Comment 2

[Robert Sayre]

blocks final.

Comment 3

[Jeff Walden [:Waldo]]

Frankly, I don't think we have time to do this along with everything else we still have to do in the way of ES5 stuff.

For another consideration, v8 doesn't implement it, and jsc probably doesn't either (the browser I have to test doesn't support it, although it's possibly just old).  I don't know what the latest IE preview does.  None of this means we shouldn't support it, of course, but it does counsel for a low priority in the immediate future.

But maybe I'm just mis-estimating how long this will take, and how long everything else we have to do will take, so we can run with it being a blocker for a bit.

Comment 4

[Jim Blandy :jimb]

For what it's worth, this is a lot less work than a normal defineProperty: the only thing that can happen is that the length becomes read-only. We don't need to worry about enumerability, deletion, and all that mess.

Comment 5

[Andreas Gal :gal]

This must be done. We can't ship without ES5 compliance. We can try to get you guys more help if needed.

Comment 6

[David Mandelin [:dmandelin]]

Jeff, Jim, are you guys going to be ready to take this on, or do you need help?

Comment 7

[Jeff Walden [:Waldo]]

I have my hands full with bug 514568 right now, and once that's done I'm currently looking at moving to compartments.  I probably don't have the time to touch this, unfortunately.

Comment 8

[Brian Hackett [Laid off!]]

Can someone explain (here or IRC) why it is possible for the array length to be read only?  From the "ECMA-262 5th Edition / December 2009" PDF I got off the ECMAScript website (this is the right spec, right?):

--- Section 15.4.5.2 (array lengths):

The length property of this Array object is a data property ...

The length property initially has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false }.

--- Section 8.6.1 (attributes of data properties):

[[Configurable]] Boolean If false, attempts to delete the property, change the property to be an accessor property, or change its attributes (other than [[Value]]) will fail.

(note) [[Writable]] is another data property attribute.

---

The length property in an Array is by default a writable, non-configurable data property.  Since it's non-configurable it can't be made configurable, and since it's non-configurable it can't be made non-writable.

Comment 9

[Jeff Walden [:Waldo]]

[[Configurable]] still permits changing the [[Writable]] field of data descriptors from true to false.  Try working through the steps for this code:

  Object.defineProperty([], "length", { writable: false });

Comment 10

[Brian Hackett [Laid off!]]

(In reply to comment #9)
> [[Configurable]] still permits changing the [[Writable]] field of data
> descriptors from true to false.  Try working through the steps for this code:
> 
>   Object.defineProperty([], "length", { writable: false });

OK, I see how that works now.  This does, however, flatly contradict 8.6.1.

Comment 11

[Brian Hackett [Laid off!]]

Talked to brendan, going to disown this bug and work on other blockers and type inference.

Comment 12

[David Mandelin [:dmandelin]]

Any takers here? If not, I can take it, but I could use a little more information about what exactly we need to do here.

Comment 13

[Jeff Walden [:Waldo]]

Brendan and I posted an awful hack in bug 598996 (more or less a dup of this one) which I think would fix this, or at least mostly fix it, with probably only spot-fixes to follow it.  But it is pretty awful, it may not be absolutely correct, it may fall over in ways you can't anticipate just from the spec (think DOM-internal property writes or something), and it may well be the wrong thing to do even for the short term.

Comment 14

[Brendan Eich [:brendan]]

I think it's time (see bug 591846) to make our js::PropertyOp internal C-ish function getter and setter based properties act completely and consistently like the data properties that they report themselves as via Object.getOwnPropertyDescriptor, etc.

If we do that, then there should not be a special case needed here.

One concern is that our js::PropertyOp-flavored accessors may not have idempotent get/get and data-like set/get behavior. That could be but too bad: we should call the getter, check SameValue, and allow the writable to non-writable change permitted by ES5 for a non-configurable property.

I was done with hardblockers and warming up to look at bug 591846 again. More brains on what I am proposing here are good, but feel free to comment there.

/be

Comment 15

[Paul Biggar]

(In reply to comment #14)
> If we do that, then there should not be a special case needed here.

OK, looks like you should take this one then. It was largely over my head anyway.

Comment 16

[Jeff Walden [:Waldo]]

IE9rc supports read-only array lengths; if we pushed through on this (well, bug 598996) we could finish it up too.  Just a point to make before we pull the plug on this entirely for this release.

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage

Comment 18

[Brendan Eich [:brendan]]

I hope this is easier now with shared-permanent dead. There may be some usable patch hunks over in bug 598996.

/be

Comment 19

[Mark S. Miller]

It apparently works to freeze an array as a whole, in which case the 'length' property appears to be non-configurable non-writable data property, as expected. However, even then, trying to defineProperty the length property to non-writable fails. Can this annoyance be fixed now? It is responsible for the only remaining "skip" entry in the SES whitelist

http://code.google.com/p/es-lab/source/browse/trunk/src/ses/whitelist.js#259 (as of this writing)

Comment 20

[Mark S. Miller]

> Object.defineProperty(Object.freeze([]), 'length', {writable: false})
InternalError: defining the length property on an array is not currently supported

Comment 21

[Jeff Walden [:Waldo]]

We're fixing it, don't worry.  It's happening as part of a larger architectural change, tho, so it's a little slow in coming.

Comment 22

[Mark S. Miller]

Now that https://bugzilla.mozilla.org/show_bug.cgi?id=858381 is fixed, does that in any way change the status of this bug?

Comment 23

[Jeff Walden [:Waldo]]

Yeah, that bug basically *was* this one, but with less ancient noise to it -- making this a duplicate.