Move ramblings about modules to the wiki page.

parent 06483127
# 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?)
4. Modules as functions might not work with async-ish stuff. We might need a postMessage
type of structure. We'll see. We could make each module a thread and modules
communicate using `nanomsg`. Or just some ZMQ compatible
\* We'll need to make a compatibility layer though, which will probably involve
automatically wrapping files in a magical IIFE.
## 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.
## A possible simple and secure module algorithm
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
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment