Welcome to MSDN Blogs Sign in | Join | Help

"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.

 

Published Thursday, December 04, 2003 3:55 PM by Greg Schechter
Filed under:

Comments

Friday, December 05, 2003 6:21 AM by Frank Hileman

# re: "Length" in Avalon

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.
Friday, December 05, 2003 9:24 AM by Rob Relyea

# Question any complexity! Avalon API feedback

Friday, December 05, 2003 8:47 AM by Greg Schechter

# re: "Length" in Avalon

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:
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconCasts.asp

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.
Friday, December 05, 2003 10:23 AM by Thomas

# re: "Length" in Avalon

What about calling it "Unit"? Length is the number of elements in an array.
Friday, December 05, 2003 11:08 AM by Joe Marini

# re: "Length" in Avalon

I think tend to agree that the name "Length" is potentially confusing - maybe "Size" would be clearer, indicating both a value and units.
Friday, December 05, 2003 11:50 AM by Greg Schechter

# re: "Length" in Avalon

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.
Friday, December 05, 2003 5:00 PM by Frank Hileman

# re: "Length" in Avalon

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.
Friday, May 21, 2004 11:36 AM by Greg Schechter

# re: "Length" in Avalon

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.
Thursday, June 03, 2004 11:51 AM by Frank Hileman

# re: "Length" in Avalon

Allow +, -, etc, and throw an exception if the units are incompatible.
New Comments to this post are disabled
 
Page view tracker