-
-
Notifications
You must be signed in to change notification settings - Fork 42
Description
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)
(wherev
is the mixin field - you cant easily do
VecT.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)
- 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)
- pass as an explicit param so smt like
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