Some time ago, a guy from Intel proposed a rectilinear geometry library for Boost. The original announcement is at http://lists.boost.org/Archives/boost/2007/09/127850.php. Renamed boost::polygon, it was recently advanced for review at http://lists.boost.org/Archives/boost/2009/06/153349.php.
Rectilinear geometry deals with axis aligned segments, rectangles, and more general shapes, which Intel needs in the design of microprocessors. One prominent feature from this library is the “isotropic API.” According to Wikipedia, Isotropy is uniformity in all directions. For boost::polygon, this means that no direction or orientation is privileged. Instead of operating on x, y, height, width, top, and bottom, all methods receive necessary directions and orientations as parameters. You say my_rect.get(LEFT) and not my_rect.get_left().When operations to compute the opposite and perpendicular on directions and orientations are added, this indirection enables generic algorithms that work in transposed and symmetric situations. For example, widget arrangement in WPF/Silverlight can be done in half the code, merging the code paths for the vertical and horizontal orientations.
Another arbitrary choice in the specification of rectangles is which subset of top, bottom, height, left, right, and width is given. Horizontally and vertically, any two of the three properties are sufficient to determine the rectangle. Although conversion between representations is easy and constructors can be defined for all combinations of properties, imperative mutation of a rectangle is again arbitrarily defined and may yield representation dependent results. For example, increasing the width is trivial and unequivocal when the rectangle stores left and width. If the rectangle consists instead of left and right coordinates, the updated rectangle could share the same left or the same right coordinate with the original, or maybe it could lie centered over it. One solution is to construct all rectangles from scratch, providing all the arguments. Another is to write and name appropriately the common variations of a rectangle, so that it can be stretched in a given direction or moved a certain way unambiguously.
Related inelegant designs are present in domains distant from geometry. First name and surname can be stored separate or joined, for example. The choice can be hidden behind an encapsulating interface, as was done with rectangle, but the work is seldom worth it when the code is new and often impractical when the code is old. I’d love to have language support for common relations between variables, so that the compiler writes the access and modification interface and the code is uncoupled to the selection of fields actually stored.
