[Webkit-unassigned] [Bug 51601] WML Parser should treat line/column number in a consistent way

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Dec 25 14:40:54 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=51601





--- Comment #4 from Peter Rybin <peter.rybin at gmail.com>  2010-12-25 14:40:54 PST ---
> > WebCore/dom/XMLDocumentParser.cpp:151
> > +    handleError(type, m, TextPosition1(WTF::OneBasedNumber::fromOneBasedInt(lineNumber), WTF::OneBasedNumber::fromOneBasedInt(columnNumber)));
> 
> This is really the only way to construct a TextPosition1?  Seems cumbersome.

This isn't really polished for everyday use so far. E.g. ZeroBasedNumber/OneBasedNumber types needs namespace qualifier. 

I think the API should be extended as needed.
The main limitation I had in mind was we should be able to merge corresponding types in the future (TextPosition0/TextPosition1 -> TextPosition), so we can't have a constructor that accepts ints and all int-dealing methods should have names saying "zero based" or "one based".
As for now TextPosition0/TextPosition1 accurately denote what kind of ints was used in the place before refactoring (to help prove that we didn't break anything).

> > WebCore/dom/XMLDocumentParser.h:108
> > +        // This method is introduced to temporary legalize existing line/column
> legalize?  What law? :)

A law that strictly separates 0-based and 1-based integers from each other -- we have to break it in this one place.
Anyway I'm fine with changing wording :)

> > WebCore/dom/XMLDocumentParserLibxml2.cpp:560
> > +    , m_lastErrorPosition(TextPosition1::belowRangePosition())
> Seems we might want the default TextPosition constructor to do this, no?  Then we wouldndt' even need these lines.

Unfortunately there are 2 defaults: "below range" and "base" (-1 and 0 for 0-based). It's fine to choose in favor of one of them, historically I just wanted to have my patch as transparent as possible.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list