20735 2013-01-22 16:59:05 +0000 n not defined in sequence algorithm 2013-01-24 14:01:35 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED FIXED P2 normal --- 1 w3c cam jmdyck mike public-script-coord w3c public-webapps-bugzilla oldest_to_newest 81940 0 w3c 2013-01-22 16:59:05 +0000 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. 81945 1 jmdyck 2013-01-22 17:10:04 +0000 When the spec introduces "an IDL sequence value S_0..n−1", surely that 'binds' both 'S' and 'n': 'n' is bound to the length of 'S' 81949 2 w3c 2013-01-22 17:17:55 +0000 (In reply to comment #1) > When the spec introduces "an IDL sequence value S_0..n−1", 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. 82045 3 cam 2013-01-24 07:15:51 +0000 (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. 82082 4 w3c 2013-01-24 14:01:35 +0000 (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.