Claire Foster

Personally I'd go with `QuatRotation` over `VersorRotation` as it's unambiguous and more well known. > There, unit quaternions have some advantages over other representations, particularly regarding singularities such as gimbal...

> I didn't know that the Unitful works exactly. In this case `Unitful` is not doing anything very fancy, it's just causing `sin(30°)` to dispatch to `sind(30)` rather than `sin(deg2rad(30))`....

> The point of the second type parameter is not keeping the angle an integer, it is keeping the angle in degrees, whereas the previous code lost exactness by converting...

Oh, hmm, well this is somewhat embarrassing, but I also implemented a ply IO library (https://github.com/FugroRoames/PlyIO.jl) and came to FileIO to discuss exactly the same issue! It's an interesting one,...

Perhaps the generic fallback could be a bit smarter, to avoid some of the issues with `Type` invariance: ``` julia load{T}(::Type{T}, args...; kwargs...) = load(supertype(T), args...; kwargs...) load(::Type{Any}, args...; kwargs...)...

The module version is interesting, but I don't think it solves the whole problem: Requiring the user to mention the backend loader _module_ has the wrong semantics from a library...

I hope JuliaArrays/StaticArrays.jl#980 isn't causing problems here? I guess it has wider consequences than expected (it was meant to be an optional concrete API for doing "normal geometry stuff" with...

Hah, you're right about that, I don't think we can (or really should) take that PR back as I think it's a major usability win for a very common use...

> define `getproperty(::QuatRotation, ::Symbol)` and special case `x`, `y`,`z`, and `w`? This makes sense to me. Code which knows it's acting on a particular concrete type can just depend on...

> In the case of `1u"°C" + 2u"°C"` one of the two is the base temperature and the other one is the delta, in any case the result of the...