3 ms·

Modules are units of encapsulation. In my experience, if you have trouble deciding where a function "foo" needs to go to -- you probably have divided your code

by Peaker 15y ago

Modules are units of encapsulation. In my experience, if you have trouble deciding where a function "foo" needs to go to -- you probably have divided your code across arbitrary/poor boundaries. Modules should have clean API's that do not leak implementation details and of course the implementation itself. If you break down the barriers between modules, you remain with only implementation details. A well-written module that's divided across meaningful boundaries can usually be read in separation of the project it is a part of and actually understood as whole. All that said, I think storage of code could be done far better than serialization in text files, but that's another matter, and whatever code editing form we use, we should still have "modules".

gnaritas 15y ago
Sounds like you didn't read the article, he specifically addressed encapsulation and an alternative way of doing it.
- Peaker 15y ago
  I read the article, and I couldn't find any explanation of how to regain the lost encapsulation. I see him mentioning anonymous inner functions and that "reusing modules" is hard. Did you mean to refer to this? Anonymous inner functions are more difficult to share across multiple components that share their intricate knowledge of the implementation details and would be stored in a module. I do not think they are a viable replacement for an explicit boundary around multiple components. About reuse of modules being hard -- I think this again stems from poorly designed module APIs and semantics. Well-designed modules (e.g: STL's modules, Haskell's data structure modules) are very easy to re-use. I completely agree with him on the difficulty/arbitrarity of module naming, though. I don't think modules should be given a made-up name, but rather found by more informative "meta-data" and addressed by auto-generated unique names.
  - gnaritas 15y ago
    I'm referring to the section where he talks about a new syntax for hiding helper functions so as not to expose them to the outside world. That was specifically about addressing your encapsulation concern.

by Peaker 15y ago

gnaritas 15y ago

Sounds like you didn't read the article, he specifically addressed encapsulation and an alternative way of doing it.

Peaker 15y ago
I read the article, and I couldn't find any explanation of how to regain the lost encapsulation. I see him mentioning anonymous inner functions and that "reusing modules" is hard. Did you mean to refer to this? Anonymous inner functions are more difficult to share across multiple components that share their intricate knowledge of the implementation details and would be stored in a module. I do not think they are a viable replacement for an explicit boundary around multiple components. About reuse of modules being hard -- I think this again stems from poorly designed module APIs and semantics. Well-designed modules (e.g: STL's modules, Haskell's data structure modules) are very easy to re-use. I completely agree with him on the difficulty/arbitrarity of module naming, though. I don't think modules should be given a made-up name, but rather found by more informative "meta-data" and addressed by auto-generated unique names.
- gnaritas 15y ago
  I'm referring to the section where he talks about a new syntax for hiding helper functions so as not to expose them to the outside world. That was specifically about addressing your encapsulation concern.