W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] DOMTokenList is unordered but yet requires sorting

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 12 Jul 2009 22:26:09 -0700
Message-ID: <63df84f0907122226y46346f36w66d58fb8141e90eb@mail.gmail.com>
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
Received on Sunday, 12 July 2009 22:26:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC