usingnamespace removal  #24

Activity

1. AndreasHefti commented on Sep 22, 2024

   

   AndreasHefti

   on Sep 22, 2024

   Last edited by AndreasHefti

   More actions

   I heavily use usingnamespace for Mixins. It's very convenient and also readable in my opinion.

   I don't like the suggested alternative for Mixins very much because its lacks readability and one would have to change a lot on the caller site as well as on the receiver side. This would lied to more boilerplate code as well.

   If usingnamespace gets removed I hope at least there will be a good alternative for Mixins. Since Mixins are a well known concept I suggest just that:

   pub fn CounterMixin(comptime T: type) type {
       return struct {
           pub fn incrementCounter(x: *T) void {
               x._counter += 1;
           }
           pub fn resetCounter(x: *T) void {
               x._counter = 0;
           }
       };
   }
   
   pub const Foo = struct {
       _counter: u32 = 0,
       pub mixin CounterMixin(Foo);
   };
   
2. andrewCodeDev commented on Sep 22, 2024

   

   andrewCodeDev

   on Sep 22, 2024

   Last edited by andrewCodeDev

   Owner

   More actions

   I don't like the suggested alternative for Mixins very much because its lacks readability and one would have to change a lot on the caller site as well as on the receiver side. This would lied to more boilerplate code as well.

   We're moving towards atomizing the implementations where the front ends essentially import what they use. Then the entry point has a single switch that breaks over the child type to the output struct. This works because const declarations can be both used like class and instance level functions:

   const std = @import("std");
   
   pub fn eq_impl(comptime T: type) type {   
       return struct {
           pub fn call(self: T, other: T) bool {
               return self.data == other.data;
           }  
       };
   }
   
   const Bar = struct {
       data: i32 = 42,
       const eq = eq_impl(Bar).call;
   };
   
   pub fn main() !void {
   
       const x: Bar = .{ .data = 42 };
       const y: Bar = .{ .data = 42 };
   
       if (x.eq(y)) // instance level
           std.log.info("It worked", .{});
       
       if (Bar.eq(x, y)) // type level
           std.log.info("It worked", .{});
   
       return;
   }

   Here you can see eq can be arbitrarily specialized and written only once. We'll then compose our way back up to how we were before. A bit more verbose but @pierrelgol and I are happy with it.

   👍React with 👍1Reacted by Andreas Hefti
3. AndreasHefti commented on Sep 22, 2024

   

   AndreasHefti

   on Sep 22, 2024

   More actions

   Yes, this is more readable. On the other hand, still, when you have Mixins with several functions, you need to declare constants for every function of the Mixin in every use of the Mixin. But surely better as the original alternative, thank you for the example.
4. pierrelgol commented on Sep 22, 2024

   

   pierrelgol

   on Sep 22, 2024

   ContributorAuthor

   More actions

   Hi @AndreasHefti, while the pattern and fundamental design we were using need to evolve, we will, of course, do our best to provide a solution that pleases everyone. Nothing is set in stone. This morning, @andrewCodeDev and I were discussing how to address this issue, and we have decided to proceed with the aforementioned pattern. Naturally, only hands-on experience will reveal how it performs at the scale of our small library. We would be grateful for any feedback or suggestions of course.
5. andrewCodeDev commented on Sep 22, 2024

   

   andrewCodeDev

   on Sep 22, 2024

   Owner

   More actions

   In fact, I opened a thread for this on Ziggit: https://ziggit.dev/t/mxin-alternative-using-const-declarations/6091