random idea: <https://twitter.com/warianoguerra/st...
# linking-together
m
v
If so, what's the difference between modules and objects then? If it's basically the same, do modules have to be first class?
m
there's not much of a difference, but you have to treat them differently. You can't access all the implicit behaviour of modules with objects, the closest I saw was the with statement in javascript and object-capability model, but why not just make modules just objects and unify the resolution logic in scopes to allow modifying/introspecting the scope chain
in many programming languages you can't pass modules as values. Imagine if the top of your module instead of being a sequence of imperative imports and renames was treated as an interface your module expects to be instantiated, and then you can override the default references (provided by the global module system), mocking and sandboxing would be builtin
v
Well, such change will make whole thing more flexible. Make mocking in tests much easier. Not sure would it make things easier though.
m
mocking, sandboxing, dependency injection and registries wouldn't be needed, that's a big simplification
also, module/object distinction would disappear and the dual resolution between scopes and global module system would disappear too
👍 1
I would like to have to think about less things 🙂
v
But this big singleton thing is not going away, right?
m
no, it's just another instance that's there by default, you can remove it explicitly or introspect it
Copy code
Newspeak is a new programming language in the tradition of Self and Smalltalk. Newspeak is highly dynamic and reflective - but designed to support modularity and security. It supports both object-oriented and functional programming.

Like Self, Newspeak is message-based; all names are dynamically bound. However, like Smalltalk, Newspeak uses classes rather than prototypes. As in Beta, classes may nest. Because class names are late bound, all classes are virtual, every class can act as a mixin, and class hierarchy inheritance falls out automatically. Top level classes are essentially self contained parametric namespaces, and serve to define component style modules, which naturally define sandboxes in an object-capability style.
don't know a lot about the details but Newspeak sounds like it's going in that direction
v
Seems like so. Don't know what to say, I still feel pessimistic about it. Things are really complicated when modules do have state.
There are two problems: dependencies of code and dependencies of state. If modules are just pack of functions without internal state, I guess it will make it easier to tackle with second problem.
m
I like immutable languages 😉
modules as stateless interfaces with associated implementations
you can layer partial implementations, like scopes to override different parts
v
yeah, good idea
m

https://youtu.be/TrNlNjwzzmc?t=5m57s

check also at minute 9
v
Yeah, he also talks about it. I don't have the vision to understand is it awesome or not.
s
I feel this is related to the idea of early/late binding (wrt time T). In Python you can 'overwrite' a module at runtime by doing something like
Copy code
import moduleA
moduleA.moduleB = myModuleB
This will affect all references to
ModuleB.foo
from within moduleA (but not all cases, only explicit global lookups of ModuleB). You can also pass modules around as objects. Are you thinking about something similar?
m
that's one part, it's kind of first class because it behaves like an object, but changes (to alter resolution of some value inside the module) are global and as you mentioned there's no way to change the values for other modules who hold a reference to moduleB (not through moduleA). What can be achieved in python sounds like monkey patching in ruby, and we know what that's like 🙂
s
Yes its similar. You can also overwrite the global
sys.modules['moduleB'] = newModuleB
and it will change for all modules that reference moduleB (because the runtime lookup goes through that dict). Monkey patching is powerful (and make mocking etc very easy) but the issue is doing it in a controlled, transactional way.
Sorry I misspoke - changing sys.modules will not change the already bound imports.
In new versions of Python you can partially hack this by implementing getattr at the top level of your module (https://www.python.org/dev/peps/pep-0562/). In general I think first class modules and good support for 'routing/binding' modules at runtime seem like a good idea.