Reference frame basics

[jbangelo]

This adds common functionality related to reference frame conversion.

• Adds some basic operations to help ease the use of the ECEF type, which gets mathematically manipulated in the reference frame transformations
• Adds a helper function to get the fractional year representation of a point in time, which is helpful in the reference frame transformations
• Adds a new Coordinate type which aggregates together position, velocity, time, and reference frame.
• Adds a new Transformation type which contains the needed information to transform between two reference frames, and can transform a Coordinate object

[JADC362]

Overall it looks good to me, based on my low Rust knowledge.

[JADC362]

Perhaps new_with_velocity? Same for new_without_velocity

[jbangelo]

At least in the standard library it's the naming convention is to only have a single new function, and alternate constructor method names take the form of with_*. See String::with_capacity

[pcrumley]

in general i think you might be better off using the builder pattern if you find that you end up needing a lot of these. i think it is probably fine as is though

[JADC362]

Perhaps this is way to do in Rust, but why don't just modify the position and velocity alone? I guess self would will have to be mutable. That's the reason for this approach?

Suggested change

	Coordinate {
	position: self.position + dt * v,
	velocity: self.velocity,
	epoch: *new_epoch,
	reference_frame: self.reference_frame,
	}
	self.position = self.position + dt * v
	self.epoch = *new_epoch

[jbangelo]

The style I typically write Rust code with definitely has more copies than is strictly necessary, and you're right that to change this method so it changes the coordinate in place without making a new copy would require making self a mutable borrow. Since this is a library it's probably better to offer both forms as options, though I'll have to figure out the right naming convention to use.

[jbangelo]

After sleeping on this some, I think this is a preferable form of the function. This produces cleaner code in the majority of cases but still allows someone to make the change in place if they desired. I will make sure to have Coordinate derive the Copy trait to make it a bit easier to use though, it's a fixed size and not terrible large so implicit copies shouldn't be a problem.

let mut c = Coordinate::new(...);

// with &mut self
c.adjust_epoch(t);

// vs just re-assign
c = c.adjust_epoch(t);