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<sub>0..n−1</sub>", 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<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.
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.