0.15.1 removed usingnamespace but unfortunately zlm makes extensive use out of it for mixins. the change notes show off an alternative approach but i dont think its appropriate here for multiple reasons:
- chaining vector operations would change from
a.add(b.sub(a).scale(f)) -> a.v.add(b.v.sub(a)).v.scale(f) (where v is the mixin field
- you cant easily do
VecT.add(a, b) without making const V = VectorMixin(Self) (which notably cant have the same name as the mixin field :/ ) then doing VecT.V.add(a, b)
- the options to get a propagated
Self are either:
- pass as an explicit param so smt like
a.v.add(&a, b) (which has runtime overhead and is repetitive and icky)
@alignCast(@fieldParentPtr(...)) (which has runtime overhead and is repetitive and icky)
its just generally unclear. i have implemented this locally simply because i needed this library updated but i can assure you this is not a nice way of doing it
so i think the best approach would be to completely generalise the Vector and Matrix structs using std.builtin.Type.StructField then add defaults for Vec2, Vec3 and Vec4. this woulddddd make the codebase alot less clear since the vec operation implementations would be filled with a bunch of meta compile time stuff but i think it would provide a better user experience + looks like the only sane way to get around the mixin restrictions
0.15.1 removed
usingnamespacebut unfortunately zlm makes extensive use out of it for mixins. the change notes show off an alternative approach but i dont think its appropriate here for multiple reasons:a.add(b.sub(a).scale(f))->a.v.add(b.v.sub(a)).v.scale(f)(wherevis the mixin fieldVecT.add(a, b)without makingconst V = VectorMixin(Self)(which notably cant have the same name as the mixin field :/ ) then doingVecT.V.add(a, b)Selfare either:a.v.add(&a, b)(which has runtime overhead and is repetitive and icky)@alignCast(@fieldParentPtr(...))(which has runtime overhead and is repetitive and icky)its just generally unclear. i have implemented this locally simply because i needed this library updated but i can assure you this is not a nice way of doing it
so i think the best approach would be to completely generalise the Vector and Matrix structs using
std.builtin.Type.StructFieldthen add defaults forVec2,Vec3andVec4. this woulddddd make the codebase alot less clear since the vec operation implementations would be filled with a bunch of meta compile time stuff but i think it would provide a better user experience + looks like the only sane way to get around the mixin restrictions