unions and enums also create namespaces. any @import creates a namespace that is a struct.
If a function's first argument is the type of the function's namespace or a pointer to the type of the namespace, you may (and by convention are encouraged to) use dot dereferencing (like python firso parameter self) as a lexical sugar to call the function with the "implicitly rearranged" first parameter ("oop style caling, but not really oop")
modules are somewhat different, in zig these are collections of code you can map to a non-filepath import string using the command line or build tool (in particular you may map something out of code root path), but these too ultimately become a namespace struct
modules (might not mean the same as module in any other given lang) ⊂ imports ⊂ structs ⊂ namespaces ⊂ types
MyModule.zig
somefield: u32,
fn get(self: @This()) u32 {
return this.somefield;
}
main.zig const Module = @import("MyModule"); // note there are build parameters necessary to make this a module
fn main() void {
var x: Module = .{.somefield = 42 };
_ = x.get() // => 42
...
A module is an import external to your project. Whether or not the import has top level fields or declarations, the mechanism is the same for structs, imports, and modules. For all imports (including modules) you should imagine an implicit `struct{...}` expression surrounding the code in your file.Do you mean object like object file (to be linked)? Those don't have member functions as far as I know.
I'm using "object" as it is commonly used; essentially a value. In e.g Java or C or C++, the struct/class is a type, and an instance of the struct/class is an object.
Accessing an object's members is a different operation from looking up a symbol in a namespace. Even in Zig.