Closed Bug 474213 Opened 16 years ago Closed 15 years ago

Add DOM NodeList Iterator to iteratorUtils.jsm

Categories

(MailNews Core :: Backend, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b4

People

(Reporter: Fallen, Assigned: Fallen)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached patch Fix - v1 (obsolete) β€” β€” Splinter Review
This patch adds an iterator to allow using for each() on a DOM NodeList. This makes some code easier to read and a bit more compact: for each (let el in nodeIterator(mynode.childNodes)) { ... } This patch also takes care of adding iteratorUtils.jsm to Sunbird.
Attachment #357553 - Flags: review?(philringnalda)
Comment on attachment 357553 [details] [diff] [review] Fix - v1 Looks fine to me other than the trailing whitespace on the throw line (well, and the way that I'm not really a mailnews reviewer, which you can neatly wallpaper over by asking neil@httl for sr).
Attachment #357553 - Flags: review?(philringnalda) → review+
Comment on attachment 357553 [details] [diff] [review] Fix - v1 I'll remove the extra space after review since its a minor issue.
Attachment #357553 - Flags: superreview?(neil)
Comment on attachment 357553 [details] [diff] [review] Fix - v1 What's wrong with for each (let el in Array.slice(mynode.childNodes))
Nice trick, that does work. In that case the only reason for the extra iterator would be to make it clearer to users what's actually happening there. Its not really clear from the Array::slice docs that this trick will help.
Well, maybe you'd like to call it something else too, such as toArray?
Attached patch Fix - v2 β€” β€” Splinter Review
Like so?
Attachment #357553 - Attachment is obsolete: true
Attachment #362028 - Flags: superreview?(neil)
Attachment #362028 - Flags: review+
Attachment #357553 - Flags: superreview?(neil)
Comment on attachment 362028 [details] [diff] [review] Fix - v2 >diff --git a/mailnews/base/util/iteratorUtils.jsm b/calendar/sunbird/modules/iteratorUtils.jsm >copy from mailnews/base/util/iteratorUtils.jsm >copy to calendar/sunbird/modules/iteratorUtils.jsm >--- a/mailnews/base/util/iteratorUtils.jsm >+++ b/calendar/sunbird/modules/iteratorUtils.jsm Bah, sucky copy & diff ... can you push the copy in a separate commit? Or better still, don't copy the file, just reference it with a relative path? >+ * @param aUseKeys If true, an array of keys will be returned instead of the values I don't see the point of this param. For a NodeList, all it does is inefficiently return an array of values 0 .. length-1 while for an Iterator it makes no difference at all...
(In reply to comment #7) > (From update of attachment 362028 [details] [diff] [review]) > >diff --git a/mailnews/base/util/iteratorUtils.jsm b/calendar/sunbird/modules/iteratorUtils.jsm > >copy from mailnews/base/util/iteratorUtils.jsm > >copy to calendar/sunbird/modules/iteratorUtils.jsm > >--- a/mailnews/base/util/iteratorUtils.jsm > >+++ b/calendar/sunbird/modules/iteratorUtils.jsm > Bah, sucky copy & diff ... can you push the copy in a separate commit? Or > better still, don't copy the file, just reference it with a relative path? Yeah two copies of the same file in the one repository doesn't sound good (especially for extensions). I vote for either referencing it, or creating a new directory (no idea of name) for things that are shared across all 3 apps.
(In reply to comment #7) > (From update of attachment 362028 [details] [diff] [review]) > >diff --git a/mailnews/base/util/iteratorUtils.jsm b/calendar/sunbird/modules/iteratorUtils.jsm > >copy from mailnews/base/util/iteratorUtils.jsm > >copy to calendar/sunbird/modules/iteratorUtils.jsm > >--- a/mailnews/base/util/iteratorUtils.jsm > >+++ b/calendar/sunbird/modules/iteratorUtils.jsm > Bah, sucky copy & diff ... can you push the copy in a separate commit? Or > better still, don't copy the file, just reference it with a relative path? I'll reference it with $(topsrcdir)/mailnews/base/util/iteratorUtils.jsm > >+ * @param aUseKeys If true, an array of keys will be returned instead of the values > I don't see the point of this param. For a NodeList, all it does is > inefficiently return an array of values 0 .. length-1 while for an Iterator it > makes no difference at all... You are right, it doesn't make sense for a NodeList. But I disagree about it making no difference for an iterator. Lets say you have a custom iterator that behaves differently depending on usage of for/foreach (i.e the iterators useKeys parameter). Not adding the parameter here would greatly limit the use of toArray() for such iterators.
Comment on attachment 362028 [details] [diff] [review] Fix - v2 OK, but all the Iterators I know (such as fixIterator) ignore useKeys.
Attachment #362028 - Flags: superreview?(neil) → superreview+
Does anything speak against checking this in (with comments considered, of course) ?
I got the ok over irc. Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/7952bfd1cd44> -> FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: