MattWarren wrote:
Is this idea to only pull in individual methods from a static class, rather than the whole class?
I would guess part of the idea would be to allow the use of free functions. Especially if
using could be scoped narrowly, it would seem nicer to say:
PointF Rotate(PointF Src, float Angle)
using Sin = Math.Sin, Cos=Math.Cos
{
double ang = Angle * Math.Pi;
return new PointF((float)(Src.X*Cos(Ang)  Src.Y*Sin(Ang)),
(float)(Src.Y*Cos(Ang) + Src.X*Sin(Ang)));
}
than
PointF Rotate(PointF Src, float Angle)
{
double ang = Angle * Math.Pi;
return new PointF((float)(Src.X*Math.Cos(Ang)  Src.Y*Math.Sin(Ang)),
(float)(Src.Y*Math.Cos(Ang) + Src.X*Math.Sin(Ang)));
}
The Math. before every Sin or Cos adds visual clutter with nearly zero informative value; moving the
Math. outside the expressions that are performing the computation would reduce the clutter there. For this simple example it's not too bad, but it's not uncommon for expressions to have many calls to methods like
Sin and Cos , and eliminating the visual clutter can be a plus. Additionally, if the code needs to be migrated on a platform which is using an ARM or other processor that can perform trig functions on a Single more efficiently than
Double, it may be helpful to be able to rework the code as:
PointF Rotate(PointF Src, float Angle)
using Sin = FastApproxMath.Sin, Cos=FastApproxMath.Cos
{
float ang = (float)(Angle * Math.Pi);
// Main expression doesn't need to change. The typecasts which were necessary to satisfy the
// compiler will be redundant if the approximate functions return `float` instead of `double`, but will
// be harmless at least in this particular case.
return new PointF((float)(Src.X*Cos(Ang)  Src.Y*Sin(Ang)),
(float)(Src.Y*Cos(Ang) + Src.X*Sin(Ang)));
}
Being able to change one line to substitute different sine and cosine functions within the method would seem nicer than having to use find/replace and hope one doesn't accidentally change something one shouldn't.
