[Mono-docs-list] Mono.Simd API Suggestions
Jonathan Pryor
jonpryor at vt.edu
Tue Nov 4 21:00:35 EST 2008
Just perusing through the Mono.Simd API, and one question (and a few
other suggestions) occurs to me: Why the non-reliance on method
overloading?
More specifically, many (most?) types have an UnpackLow() method:
public class Vector2L {
public static Vector2l UnpackLow (Vector2l x, Vector2l y);
}
public class Vector8s {
public static Vector8s UnpackLow (Vector8s x, Vector8s y);
}
// ...
Why do we require type qualification for these methods, so that to call
them you need Vector2L.UnpackLow() or Vector8s.UnpackLow()? Why not
instead use method overloading on a common type:
static class VectorOperations /* [0] */ {
public static Vector2l UnpackLow (Vector2l x, Vector2l y);
public static Vector8s UnpackLow (Vector8s x, Vector8s y);
// ...
}
The benefit to this are twofold:
1. Documentation: the class-level documentation will only contain
members which are specific to the given type (except for overloaded
operators, but those can't be located anywhere else anyway...).
Meanwhile, semantically equivalent operations would all be located
in and documented in the same place.
2. Type migration: if the developer starts with Vector8s and needs to
migrate to Vector4f, fewer code changes will be required (e.g. you
won't need to change every UnpackLow() method call to refer to your
new type).
On a completely different note (and to start a bikeshed discussion ;-),
why "ShiftRightLogic"? Wouldn't "LogicalRightShift" be more
conventional? We should also avoid abbreviations, so
SubtractWithSaturation() would be better than SubWithSaturation()...
Thoughts?
- Jon
[0] or some better name. `VectorOperations' is rather verbose, but the
name chosen doesn't really matter as far as this question is
concerned...
More information about the Mono-docs-list
mailing list