4 ms·

> You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. And you can instantiate

• Jtsummers 4y ago
  You don't need multiple module instances, the modules just need access to details about the opaque type or private portions of a type. If you've ever seen this in a C header: struct foo; That's an example of an opaque type. Put that in a header, and any function can make use of it in any other C file, they just can't access its innards (well, it's C so you actually can if you know how its contents are packed). Functions can accept them as parameters and return them knowing nothing but that opaque type and some additional function signatures like this (to do something useful with it): struct foo make_foo(...); // or struct foo* void print_foo(struct foo*); // or struct foo So I can write something like this: // main.c #include "foo.h" // other includes void do_something(struct foo* f) { // lots of code print_foo(f); } int main(int argc, char* argv[]) { struct foo f = make_foo(a_param); do_something(&f); return 0; } In a hypothetical C you could do something like this: struct foo { int a; char b; private; }; That last bit indicating that there is something there, but not what it is. Then somewhere you'd have a fuller definition: struct foo { int a; char b; // private expanded float c; } Which would be used by functions which are meant to actually operate on the rest of this structure. In this case, anything that knows of struct foo can directly access its "public" fields of a and b, but have no clue about the remaining fields.