[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