"Length" in Avalon

Frank Hileman wonders about the Length type in a comment on a usability post to Steven Clarke's blog.  Here is his comment:

“..., like Length to represent a scalar. It is a scalar, why not use a double? This is what users want.“

Length is more than just the scalar value.  It also represents the units – thus Length allows specification in points, device independent pixels, centimeters, etc.  While one could imagine just taking doubles and having utlity functions to convert unit-based values into doubles, Length also allows for relative unit specification – for instance 62.5%.  This is not convertible by the user into a double value, thus a structure, like Length, is required to represent it.


Comments (9)
  1. Frank Hileman says:

    Yes, I know this is why Length is used, and it maps perfectly onto the CSS and html tradition and object model. But consider the use in graphics. A user will want to specify Length in world coordinates. In that case a double is sufficient and preferable. So if there was an implicit conversion from double to a Length of type "independent pixel" (which I suppose is world coordinates) it would not be so clumsy. You do not have to allow an implicit conversion the other way. There is a conflict here between the flow layout typical use, and the absolute positioning typical use.

  2. Greg Schechter says:

    There are multiple drivers leading to this.

    One is that we want to provide a platform that unifies graphics, UI and documents as much as possible, and that sometimes leads to compromises in one area or another that benefits the whole. In the case of Length, we want to provide a single type at the Framework level.

    Regarding the providing of an implicit cast… this is something that is strongly discouraged in our design guidelines as, while it’s conventient, can be misleading for users. The current set of internal guidelines (which will ultimately be published more broadly) is more definitive about this, but there’s also reference to it in the currently published set:


    Finally, Length starts to appear at the "element" level of the system. Pure graphics-oriented applications may choose to use lower level access at the Visual level directly using the System.Windows.Media.DrawingContext to issue drawing instructions. All of these APIs take doubles directly that are interpreted as device independent pixels.

  3. Thomas says:

    What about calling it "Unit"? Length is the number of elements in an array.

  4. Joe Marini says:

    I think tend to agree that the name "Length" is potentially confusing – maybe "Size" would be clearer, indicating both a value and units.

  5. Greg Schechter says:

    Agreed that it can be confusing. However, we haven’t seen better alternatives.

    For instance "Unit(4.0, UnitType.Points)" suggest that a "unit" is being create, but in fact, it’s almost exactly the opposite — an physical length measurement of something with a particular value and in a particular unit is created. The primary point of it is that it does represent a physical measure of length.

    Size is also confusing because there has been much precedent in the past for Size to mean a 2D size (width and height) and, in fact, in Avalon we use the Size type to denote just that as well.

  6. Frank Hileman says:

    I thought the implicit cast was only discouraged when it loses data or precision. Going from a double to a Length this is not the case. In this case I would argue both are in the same "domain," the double simply being another form of a device independent pixel Length. An explicit cast operator from Length to double, converting to device independent pixels (if possible), would also be nice. Well, too bad these conversion operators will not be provided, because the code does not look good with all those Length constructors.

  7. Greg Schechter says:

    We followed up on this over here, and it was pointed out that "domain" isn’t really the only issue. It also has to do with whether the operations used on the "sub type" of the conversion (double in this case) need to be valid on the "super type" of the conversion (Length in this case).

    For double/Length, this isn’t the case, as +, for instance, isn’t defined on Length, nor should it be, since adding Lengths of different unit types doesn’t make sense.

    So, I agree, it’s somewhat more painful than one would like it to be, but our feeling is that that’s better than the confusion it would cause by not having a properly applied implicit conversion.

  8. Allow +, -, etc, and throw an exception if the units are incompatible.

Comments are closed.

Skip to main content