[Bug 22509] Some way to express array as readonly and fixed length

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22509

Rick Waldron waldron.rick@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |waldron.rick@gmail.com

--- Comment #1 from Rick Waldron waldron.rick@gmail.com ---

Is frozen-ness insufficient?

Contact us to advertise here
# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22509

David Bruant bruant.d@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |bruant.d@gmail.com

--- Comment #2 from David Bruant bruant.d@gmail.com --- (In reply to comment #0)

Would be nice if the spec provided some way in IDL to express that an array is readonly and/or fixed length.

Are there cases of fixed length in the platform?

(In reply to comment #1)

Is frozen-ness insufficient?

I don't think there is a WebIDL way to express that an object is frozen yet (though I agree that could be a solution here)

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22509

Boris Zbarsky bzbarsky@mit.edu changed:

       What    |Removed                     |Added

             CC|                            |bzbarsky@mit.edu

--- Comment #3 from Boris Zbarsky bzbarsky@mit.edu ---

frozen-ness is not the right thing.

The point of readonly or fixed-length arrays is to return an arraylike object to a caller with the following properties:

1) The caller can read things from the arraylike. 2) The caller cannot write things to the arraylike. 3) The callee can write things to the arraylike as needed.

Most cases where you'd not want the callee to later modify the object just want pass-by-value semantics and actual JS arrays.

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22509

--- Comment #4 from Rick Waldron waldron.rick@gmail.com --- (In reply to comment #3)

frozen-ness is not the right thing.

The point of readonly or fixed-length arrays is to return an arraylike object to a caller with the following properties:

1) The caller can read things from the arraylike. 2) The caller cannot write things to the arraylike. 3) The callee can write things to the arraylike as needed.

Most cases where you'd not want the callee to later modify the object just want pass-by-value semantics and actual JS arrays.

Got it, thanks for the clarification

# bugzilla at jessica.w3.org (4 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22509

Cameron McCormack cam@mcc.id.au changed:

       What    |Removed                     |Added

     Whiteboard|                            |[v1]
# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22509

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

             CC|                            |d@domenic.me
     Resolution|---                         |WONTFIX
         Status|NEW                         |RESOLVED

--- Comment #5 from Domenic Denicola d@domenic.me ---

We used to have this, in T[]. It was removed in favor of FrozenArray and a general movement toward a different pattern of returning a new frozen array object each time. I think we won't go back to a T[]-like world, unless ES somehow add readonly-but-not-immutable arrays as a first-class concept.

Want more features?

Request early access to our private beta of readable email premium.