[webkit-reviews] review granted: [Bug 24763] Position should support neighbor-anchored positions : [Attachment 29275] Pre-computed and store AnchorType and isLegacyEditingPosition on Position during construction

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 6 09:29:43 PDT 2009


Darin Adler <darin at apple.com> has granted Eric Seidel <eric at webkit.org>'s
request for review:
Bug 24763: Position should support neighbor-anchored positions
https://bugs.webkit.org/show_bug.cgi?id=24763

Attachment 29275: Pre-computed and store AnchorType and isLegacyEditingPosition
on Position during construction
https://bugs.webkit.org/attachment.cgi?id=29275&action=review

------- Additional Comments from Darin Adler <darin at apple.com>
> -Element *Position::element() const
> +Element* Position::element() const

It seems to me that both element() and node() need to eventually be private
unless it's clearer whether they should be named anchorNode or what.

> +    Position()
> +	   : m_offset(0)
> +	   , m_anchorType(PositionIsOffsetInAnchor)
> +	   , m_isLegacyEditingPosition(true) // FIXME: Switch the null position
to not be in legacy mode
>      {}

Braces should be on separate lines.

>      void clear() { m_anchorNode.clear(); m_offset = 0; }

This should set m_anchorType to PositionIsOffsetInAnchor and set
m_isLegacyEditingPosition to true.

> +    // These should only be used for PositionIsOffsetInAnchor positions,
unless
> +    // the position is a legacy editing position.
> +    void moveToPosition(PassRefPtr<Node> anchorNode, int offset);
> +    void moveToOffset(int offset);

Do the implementations have an assertion to this effect? Also, I think that
moveToPosition seems like a full assignment that could entirely wipe out the
old value of Position. I don't think a Position should necessarily have a
persistent mode that outlasts it value. Obviously, moveToOffset is different in
this respect since it's not a full assignment.

r=me


More information about the webkit-reviews mailing list