Closed Bug 672055 Opened 14 years ago Closed 14 years ago

Use nsCharSeparatedTokenizer to parse number-optional-number attributes

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: longsonr, Assigned: longsonr)

Details

(Whiteboard: [inbound])

Attachments

(1 file, 2 obsolete files)

No description provided.
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → longsonr
Attachment #546333 - Flags: review?(dholbert)
Comment on attachment 546333 [details] [diff] [review] patch Looks good! One thing that I stumbled over at first, though: so it looks like lastTokenEndedWithWhitespace() would end up returning true for the first token in all the following strings: > "first, last" <--- discussed below > "first ,last" > "first , last" > "first last" (but would return false for "first,last" or "first," or "first") However, in the initial line above, it's not intuitively clear that the first token actually "ends with whitespace" -- we're tokenizing at the ',' character, so my first impression is that the first token ends _at the comma_ (and hence does *not* "end with whitespace"). I'm not sure this distinction matters that much, though -- it's just non-obvious from the function-name that it'll return true in this sort of situation. Could you add a header comment saying something like "Returns true if there was whitespace after the most recently parsed token. This includes whitespace after any separator character that was encountered." r=dholbert with that clarification. You should get someone else (maybe roc?) to sign off on the /xpcom/ds/ chunk, too.
Attachment #546333 - Flags: review?(dholbert) → review+
(In reply to comment #2) > Comment on attachment 546333 [details] [diff] [review] [review] > patch > > Looks good! One thing that I stumbled over at first, though: so it looks > like lastTokenEndedWithWhitespace() would end up returning true for the > first token in all the following strings: > > "first, last" <--- discussed below > > "first ,last" > > "first , last" > > "first last" > (but would return false for "first,last" or "first," or "first") I'm not sure it makes sense to call that method then. I'll try adding an NS_ABORT_IF_FALSE that we're at the end.
(In reply to comment #2) > Comment on attachment 546333 [details] [diff] [review] [review] > patch > > However, in the initial line above, it's not intuitively clear that the > first token actually "ends with whitespace" -- we're tokenizing at the ',' > character, so my first impression is that the first token ends _at the > comma_ (and hence does *not* "end with whitespace"). Actually I can have the flag return fals in that case as I don't really care what the value is if lasttokenendedswithseparator is true. > > I'm not sure this distinction matters that much, though -- it's just > non-obvious from the function-name that it'll return true in this sort of > situation. Could you add a header comment saying something like "Returns > true if there was whitespace after the most recently parsed token. This > includes whitespace after any separator character that was encountered." I'll fix the logic instead so it's more intuitive and get roc to sr.
Attached patch address review comment (obsolete) — Splinter Review
Attachment #546333 - Attachment is obsolete: true
Attachment #546354 - Flags: superreview?(jonas)
Attachment #546354 - Attachment is obsolete: true
Attachment #546395 - Flags: superreview?(jonas)
Attachment #546354 - Flags: superreview?(jonas)
Attachment #546395 - Flags: superreview?(jonas) → superreview+
Whiteboard: [inbound]
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: