a symptom of poor language design (C’s single global namespace), a valuable feature, or something else?
Is there a scenario in zig where this would be necessary, or does zig avoid this entirely?
I generally like to think that software should be explicitly written to support it’s use cases. Allowing these linker tricks in your language (like Python’s mock, or manipulating the linker) are adding complexity and confusion…the software should be explicit whether it intends to support this or not. And users should pound sand if it doesn’t work, or you know, change the software!
Zig definitely supports “tricks” like this: any Zig project which exports a public API as a dependency for other Zig projects, for example, may be mocked.
I haven’t kept up with the project too much, but @mitchellh’s libxev (also std.Io) exposes this as a possibility on purpose, to allow for greater genericity over the target platform (in the former case) or the kind of IO system your project wants in the latter.
I agree that @MasonRemaley’s replacement of dlopen is so big-brained as to boggle my mind reading the blog post, but imo it’s potentially worth thinking about creative uses of a public API as “working as expected” if perhaps not “intended”