This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dev.w3.org/2006/webapi/WebIDL/#es-sequence Where it says: [[ An IDL sequence value S0..n−1 of type sequence<T> is converted to an ECMAScript Array object as follows: ... While i < n: ]] n is not defined to be the length of the sequence.
When the spec introduces "an IDL sequence value S<sub>0..n−1</sub>", surely that 'binds' both 'S' and 'n': 'n' is bound to the length of 'S'
(In reply to comment #1) > When the spec introduces "an IDL sequence value S<sub>0..n−1</sub>", surely > that 'binds' both 'S' and 'n': 'n' is bound to the length of 'S' sure, but it's more consistant with the other algorithms if n is explicitly defined in the algorithm itself. The spec defines "Let n be the ..." in 5 other places in the spec.
(In reply to comment #2) > sure, but it's more consistant with the other algorithms if n is explicitly > defined in the algorithm itself. My intent was to use "blah_0..n-1" for list variables that algorithms use, and not for IDL values like sequences. So I've changed the three instances of "blah_0..n-1" that name or define IDL sequence values, but I'll leave the remaining ~10 uses of "blah_0..n-1" without an preceding definition of n when they're naming/defining lists.
(In reply to comment #3) > (In reply to comment #2) > > sure, but it's more consistant with the other algorithms if n is explicitly > > defined in the algorithm itself. > > My intent was to use "blah_0..n-1" for list variables that algorithms use, > and not for IDL values like sequences. So I've changed the three instances > of "blah_0..n-1" that name or define IDL sequence values, but I'll leave the > remaining ~10 uses of "blah_0..n-1" without an preceding definition of n > when they're naming/defining lists. mkay, but note that the 0..n-1 seems overly fancy (when you are already working on n in the algorithms) and it's already confused me during implementation. Please try to avoid unnecessary "mathematical-looking" constructs in the spec to keep the spec as easy to read as possible.