[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