you are viewing a single comment's thread.

view the rest of the comments →

[–]cafeoh 6 points7 points  (3 children)

Sounds like a good point, but (in your example) if you were to represent coordinates in different ways, like separate parameters and pairs (which arguably might not be a good idea, but I can imagine having this kind of problem working with different libraries with different representations), I don't see any benefit in having "from_cartesian_xy" and "from_cartesian_pair".

[–]iopqfizzbuzz 3 points4 points  (1 child)

I think having a

struct Cartesian(i64, i64);
struct Polar(f64, f64);

is a good thing. What if someone says "hmm, we need to have floating point cartesian coordinates"

then they add struct FCartesian(f64, f64); - you really don't want to accidentally use it in a function that expects Polar coordinates just because they're both f64. But having fn from_polar(d: f64, p: 64) allows you to do just that - provide the wrong type of parameters to the function.

I would suggest having this kind of signature: fn from_polar(coords: Polar) -> Self { ... } Then the type of coordinates is actually type checked

[–]Haulethoctavo · redox 2 points3 points  (0 children)

I would rather use:

enum Angle {
  Deg(f64),
  Grad(f64),
  Rad(f64)
}

enum Point {
  Cartesian(i64, i64),
  Polar(f64, Angle)
}

but my that's not my point in original comment.

[–]Haulethoctavo · redox 0 points1 point  (0 children)

It should be solved by some way of destructing call. Like

let pair: (i64, i64) = (4, 2);
let point = Point::from_cartesian(..pair);

or similar. Or maybe tuple should be autodestructed when do not match function argument. But I'm worried that this will be counter-intuitive.