Update README.md

README.md

@@ -42,3 +42,57 @@ I've got a fancy Gitlab Pipeline that compiles and tests the program on both
 Ubuntu and Alpine Linux. Mostly because it would slow things down if I had to
 always compile against Alpine Linux when my dev environment is Bash for Windows.
 
+## Module strategy
+
+Still working on it. Current thoughts:
+
+1. No magic. Node made a mistake when it decided to automatically wrap files
+   in an IIFE to make it "easier". It's a deceptive abstraction.
+2. No globals. Implicit globals are mistakes waiting to happen.
+3. Given 1 and 2, I'm leaning towards Modules are Functions. End of Story.
+   (Since functional programming is superior anyway, why encourage anything else?)
+
+### Packages vs Modules
+
+Node makes a distinction between packages and modules. This is confusing and annoying to me.
+However it IS important to distinguish between "files I wrote and trust" and "libraries written by a third party I don't trust".
+
+I also don't want to encourage users to use giant monolithic files.
+
+So here's what I'm thinking:
+
+- All file modules have a single top-level function.
+- All file modules are named the same name as their top-level function (minus the '.js').
+- All file modules in the same package are loaded into a shared context:
+  - All file modules in a package share the same heap.
+  - All file modules are in that context's "global" scope.
+
+People should love it because it
+- is less typing. You never have to `require('./some/local/file')`
+- enforces consistancy. You always know what filename goes with what function.
+- is simple to browserify. `cat **.js` and wrap in an IFFE.
+ 
+What about subfolders? Indeed that is sometimes very convenient for organizational purposes.
+I'm gonna break with the stupid `index.js` convention (because having 20 tabs open
+in your editor that all say `index.js` is not helpful. At all.) and say that
+you can refactor `'Module.js'` by putting it in a folder of the same name:
+`'Module/Module.js'`. Then that function will be registered as `global.Module`
+and any sibling files in that folder are placed into the same closure. E.g.
+folder directories = anonymous closure, where only `FolderName.js` gets exposed.
+That allows some level of portability (copy a folder from an existing project to
+a new project) and allows functions to be organized while still allowing foldered
+functions access to all the module-global functions. Essentially what I'm hoping
+is that we can tie the "information hiding" aspect of closures to the "visibility
+hiding" of file directories. In the end, we need a representation that is NOT
+tied down to a file-system per se. Because file systems need to die. But there
+is definitely a use case where you want to separate some parts from other parts,
+even though you trust both parts and need them to be able to interact directly
+with each other sometimes. What should we call that? Weak encapsulation?
+
+So next is the great question of how "packages" aka functions that don't trust
+each other should interact. Ideas include:
+- dependency injection
+- packages are services
+- shared heaps for argument passing (hmm that ties in with WebAssembly ideas doesn't it?)
+- postMessage based interaction?
+- proxy objects? have awesome revocation semantics