Last Comment Bug 672055 - Use nsCharSeparatedTokenizer to parse number-optional-number attributes
: Use nsCharSeparatedTokenizer to parse number-optional-number attributes
Status: RESOLVED FIXED
[inbound]
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla8
Assigned To: Robert Longson
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-16 09:55 PDT by Robert Longson
Modified: 2011-07-25 06:13 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (13.13 KB, patch)
2011-07-16 09:55 PDT, Robert Longson
dholbert: review+
Details | Diff | Splinter Review
address review comment (9.53 KB, patch)
2011-07-16 15:18 PDT, Robert Longson
no flags Details | Diff | Splinter Review
address review comment properly (9.13 KB, patch)
2011-07-17 00:29 PDT, Robert Longson
jonas: superreview+
Details | Diff | Splinter Review

Description Robert Longson 2011-07-16 09:55:12 PDT

    
Comment 1 Robert Longson 2011-07-16 09:55:56 PDT
Created attachment 546333 [details] [diff] [review]
patch
Comment 2 Daniel Holbert [:dholbert] (mostly OOTO until Aug 9th) 2011-07-16 12:10:15 PDT
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.
Comment 3 Robert Longson 2011-07-16 13:47:41 PDT
(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.
Comment 4 Robert Longson 2011-07-16 15:03:43 PDT
(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.
Comment 5 Robert Longson 2011-07-16 15:18:44 PDT
Created attachment 546354 [details] [diff] [review]
address review comment
Comment 6 Robert Longson 2011-07-17 00:29:26 PDT
Created attachment 546395 [details] [diff] [review]
address review comment properly
Comment 7 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-07-25 06:13:17 PDT
http://hg.mozilla.org/mozilla-central/rev/7a9c173b0898

Note You need to log in before you can comment on or make changes to this bug.