Operating an a struct using self or not?

Brainstorming
1

I am writing a little lemmings game.
And walking into a design problem.

Let me say I have a struct in side game.lemming.zig:

const Lemming = struct {

    fn walk(self: *Lemming) bool {
        // program against self.
    }

}

Then I decide to put a new piece of code inside another zig file, because it is quite big.
New file: game.lemming.special.zig

fn do_special(self: *Lemming) bool {

}

This has to be a raw function, because I cannot extend the Lemming struct in another file.
So now the code gets messy. Sometimes I have to call

lemming.walk();

and sometimes

do_special(lemming);

Which puts me in an OCD situation.
“Shall I operate on all structs only with raw functions?”

2

If you put these functions only into separate files because of their size, you could also just add member functions that forward to the global ones which are declared in the other files. It’s a bit more work, but it gives you a clean interface and all functions are declared in one place:

const special_file = @import("lemmings/special_file.zig");

const Lemming = struct {

    fn walk(self: *Lemming) bool {
        // program against self.
    }
    fn do_special(self: *Lemming) bool {
        return special_file.do_special(self);
    }
}

By the way you’ll actually see this pattern commonly when it comes to handling OS-specific code, since now you could switch out the implementation based on your requirements, e.g.

const special_file = switch (builtin.os.tag) {
  .windows => @import("lemmings/windows_always_needs_special_treatment.zig")
  else => @import("lemmings/special_file.zig");
};
11 Likes
3

You can simply “import” the special function into the Lemming struct’s namespace like this:

const Lemming = struct {

    fn walk(self: *Lemming) bool {
        // program against self.
    }

    const do_special = @import("game.lemming.special.zig").do_special;

}

That way, you can do lemming.do_special() as well, and you don’t have to copy the function’s signature into the original file.

24 Likes
4

I’m also interested in the design aspect, especially when the game grows and more and more features are implemented which might affect the lemming. I’m working with C++ codebases which have multiple god types where a lot of features of the whole game are imported/included into one file/type because of this. This leads to large rebuilds for small changes and slow compile times.

I always thought a better way might be to put some logic into other files which take the Lemming. So that only the features, which require the logic, import this file and it does not clutter all other features which depend on the Lemming itself (although a Lemmings game would probably not reach the scope of this).

I’m not sure how compile-time/rebuilds are impacted in Zig which has no header files and if this should also be taken into account for such a design.

5

in my experience I’ve never noticed a difference, maybe there is but if there is one it’s probably too small to measure. In C++ it’s really slow though I sympathize with you, such a horrid compiler, I used to work on a codebase where each compile would take 6 min which already felt unbearable, I can’t imagine people who needed multiple hours/days to compiler programs before.

6

Back in the day I worked on a system where a full debug rebuild on a beefy dev desktop took a week. Luckily you never really needed to do that, and building just your component was 20 min.

3 Likes
7

Incredible… I can just see the bytes walking through the mud :slight_smile:

8

damn, 20min would drive me crazy, i love the feedback loop of the instant recompile of zig.

9

Having it compile on your own machine was way better than handing a 2ft stack of punch cards to an intern at the window and picking up your printout the next morning: “Syntax error on line 1237”

1 Like
10

oh my god, we have it so good nowadays, can’t imagine the pain of working on something for days, compiling it, and a week later getting hit by the syntax error, no wonder so much software engineer, became landscaper, or farmer ahah

1 Like
11

Once upon a time, I worked in the development department of an ERP system whose core was written in C++. The build process took 5 hours. The build started at 00:00, and at 05:00, deployment to all test servers was launched; after that, automated tests were started. By the time I got to work at 09:00, the automated test reports were already available, and a new cycle would begin. :smiling_face_with_sunglasses:

1 Like
12

Reading this gave me PTSD

.. submitting tiny patches to a Jenkins CI queue that took an hour or more to reach your job. CI runs with tests that took minimum 45 minutes, with a 40% chance of failing due to flakes .. which means resubmit the job back on the queue .. which infers you need to be vigilant for the whole process, or miss the window if it fails. If that means missing lunch, then yeah, miss lunch.

Sometimes you were 45 minutes away from a green build, sometimes several days. If it was days, you were guaranteed to have new merge conflicts by then.

Basically getting paid to sit there and watch paint dry.

13

That’s not quite right. Each developer tested the functionality they were working on on their own computer with the environment set up, and that was quite fast. But the entire product was very large, and its full build, including all the changes made by all the developers, took 5 hours.
This doesn’t mean that the developer had to wait that long to test each change. But it did take that much time to check the entire product with all the changes that had been made.