[webkit-dev] Int/FloatPoint and Int/FloatSize

Levi Weintraub leviw at google.com
Thu Jan 3 10:00:15 PST 2013

Hi Steve,

When converting the old tx/ty paint offsets to use IntPoint and IntSize
(later LayoutPoint/Size) we had some discussion around this. Darin Adler
wrote some good advice here:
https://bugs.webkit.org/show_bug.cgi?id=61562#c2 -- quoting:
"It’s hard to tell points and sizes apart when we have nested coordinate
systems. The distance from the top left to a rect is a “size”, yet it’s
expressed as an origin point. I think that whenever we can’t decide, we
should use IntPoint, and we should use IntSize only when it’s clearly the
size of something, not just a distance (a point described relative to
another point)."


On Wed, Jan 2, 2013 at 11:21 PM, Steve Block <steveblock at chromium.org>wrote:

> Hi webkit,
> I was hoping that somebody could clarify the policy regarding the
> correct use of Int/FloatPoint vs Int/FloatSize.
> It seems that xxxPoint is consistently used to represent a position,
> which makes sense. However, when representing the position of one
> point relative to another, both xxxPoint and xxxSize are used, which
> seems inconsistent. I'd expect that xxxPoint should be used for this
> case of a relative position, since its x(), y() and length() methods
> make more sense than the width() and height() methods of xxxSize.
> However, the operators [1] for subtracting one xxxPoint from another
> encourage the use of xxxSize. I recognize that in some situations, you
> need really do want to represent the difference between two points as
> an area or size, but this seems the less common case, and it might be
> better to make it more explicit [2].
> My questions are ...
> - What (if any) is the correct policy?
> - Would people welcome changes to encourage that policy?
> Thanks,
> Steve
> [1] eg 'inline FloatSize operator-(const FloatPoint&, const FloatPoint&)'
> [2] Perhaps something like 'static FloatSize
> FloatSize::fromCornerPoints(const FloatPoint&, const FloatPoint&)'.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130103/6d187bc4/attachment.html>

More information about the webkit-dev mailing list