[whatwg] DOMTokenList is unordered but yet requires sorting
Jonas Sicking
jonas at sicking.cc
Sun Jul 12 22:26:09 PDT 2009
On Sun, Jul 12, 2009 at 9:00 PM, Ian Hickson<ian at hixie.ch> wrote:
> On Mon, 15 Jun 2009, João Eiras wrote:
>> On Mon, 15 Jun 2009 21:38:05 +0200, Darin Adler <darin at apple.com> wrote:
>> > On Jun 15, 2009, at 12:22 PM, Ian Hickson wrote:
>> > > On Tue, 9 Jun 2009, Erik Arvidsson wrote:
>> > > >
>> > > > I was about to follow up on this. Requiring sorting which is O(n
>> > > > log n) for something that can be done in O(n) makes thing slower
>> > > > without any real benefit. Like João said the order should be
>> > > > defined as the order of the class content attribute.
>> > >
>> > > Fair enough. Done.
>> >
>> > Since DOMTokenList requires uniqueness, then I suspect it's still O(n
>> > log n) even without sorting, not O(n).
>>
>> Oh, I have forseen that. Is it really necessary to remove duplicates ? I
>> imagine DOMTokenList to be similar to what can be achieved with a
>> String.split(), but then it would be just more duplicate functionality.
>
> If we don't remove duplicates, then things like the .toggle() method could
> have some quite weird effects.
Such as? The only one I can think of is that calling .toggle() would
remove multiple items. I don't see that as a problem?
Define .remove() as removing all tokens with the given value, and .toggle() as:
function toggle(token) {
if (this.contains(token))
this.remove(token);
else
this.add(token);
}
I definitely think it'd be worth avoiding the code complexity and perf
hit of having the implementation remove duplicates if they appear in
the class attribute given how extremely rare duplicates are.
/ Jonas
More information about the whatwg
mailing list