4 ms·

You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. If you think that `obj.f()

You'd use a module to hides things. Some OOP languages conflate modules (which do information-hiding) with private fields in classes. If you think that `obj.f()` and `f(obj)` should mean different things, then your reasoning is likely faulty.

jakelazaroff 4y ago
To clarify, I’m talking about private fields in each object/struct. You could say all functions defined in the same module get access to private struct fields. That works until you want a more specialized version of some of those functions — essentially, a different module that has access to protected fields. Here’s another example. You’re writing a function `g` that accepts an object of type `Foo` and calls function `f` on it. You have a default implementation of `f`, but you also want to let the caller supply their own implementation. If you have some way of attaching behavior to a type — classes, typeclasses, etc — this is trivial. If not, your function has to explicitly ask for every single function from the caller.
still_grokking 4y ago
> You'd use a module to hides things. And than you need functors and existential types to recreate classes… ;-) Your reasoning is likely faulty if you don't see that OOP is a very advanced and great module system. The only problem with OOP is that it's often misused for other things that aren't modules. But that's a different story.
theteapot 4y ago
> 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 multiple instances of these "modules"?
- 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.

jakelazaroff 4y ago

To clarify, I’m talking about private fields in each object/struct. You could say all functions defined in the same module get access to private struct fields. That works until you want a more specialized version of some of those functions — essentially, a different module that has access to protected fields. Here’s another example. You’re writing a function `g` that accepts an object of type `Foo` and calls function `f` on it. You have a default implementation of `f`, but you also want to let the caller supply their own implementation. If you have some way of attaching behavior to a type — classes, typeclasses, etc — this is trivial. If not, your function has to explicitly ask for every single function from the caller.

still_grokking 4y ago

> You'd use a module to hides things. And than you need functors and existential types to recreate classes… ;-) Your reasoning is likely faulty if you don't see that OOP is a very advanced and great module system. The only problem with OOP is that it's often misused for other things that aren't modules. But that's a different story.

theteapot 4y ago

> 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 multiple instances of these "modules"?

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.