Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API issues to consider fixing for 3.0 #50

Open
airbreather opened this issue Jul 5, 2019 · 0 comments
Open

API issues to consider fixing for 3.0 #50

airbreather opened this issue Jul 5, 2019 · 0 comments

Comments

@airbreather
Copy link
Member

airbreather commented Jul 5, 2019

Writing these up really quickly because it's really late in the morning for me...

  1. TransformList(IList<double[]>) and Transform(double[]) seem outdated
  2. Since everything goes through Transform(ref double x, ref double y, ref double z), we can probably get rid of DimSource and DimTarget?
    • AffineTransform could probably have its own non-abstract versions of these properties.
  3. All methods implemented via throw new NotImplementedException() are unused, let's eliminate them
  4. XML doesn't seem to be used, yet every MathTransform subclass must implement it.
  5. Forcing all implementations to provide a way to get WKT for their own instance is awkward. Is there a better way to accomplish this goal?
  6. Do we need Transform(double x, double y) / Transform(double x, double y, double z) when we could just point people to the versions that take in ref parameters?
    • Overloads that differ only by the presence / absence of ref aren't CLS-compliant.
  7. IMO we should strongly favor having separate overloads instead of default arguments the "z or no z?" case (public void Transform(Span<XY> xys, Span<double> zs = default, int strideZ = 0)).
    • As-is, this clashes with the notion of "if you don't have Z, then don't pass in anything for Z". Even though you're not explicitly passing in a value in the C# source code, the caller is still providing a value, and it's still visible through IntelliSense.
  8. Subclasses should be required to implement at most one of either "invert myself" or "create an inverted copy of myself". IMO, we should drop Invert().
@airbreather airbreather added this to the 2.0 Candidate milestone Jul 5, 2019
@airbreather airbreather changed the title API issues to consider fixing for 2.0 API issues to consider fixing for 3.0 Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant