4 ms·
The particularly frustrating thing, when I've started thinking about optimizing boot time at a VM level, is that it's near-impossible to "understand" what loadi
by burke 9y ago
The particularly frustrating thing, when I've started thinking about optimizing boot time at a VM level, is that it's near-impossible to "understand" what loading a file actually does, since it's all just evaluated in a single namespace.
It would be great if we somehow had a way to load a module-as-file without unknown side-effects, and without depending so deeply on the other contents of the global namespace.
But this is basically describing a complete overhaul of most of what makes ruby ruby, so... ¯\_(ツ)_/¯
- chrisseaton 9y agoYes if there were special Ruby source files that only had classes and modules at the top level, and only defined nested classes and modules and methods in those, then it would be a lot quicker to load things.
- burke 9y agoYep. But even then though, what if: class A B = "c".freeze end And elsewhere: class String def freeze raise "because I can, that's why" end # or even method_added, TracePoint, ... end It feels like something should be possible here, but it's really steep uphill battle.
- chrisseaton 9y agoRight - that's why I said nothing but methods and nested classes - expressions in method bodies would be disallowed. And tracing and method added hooks and so on, yes. You could say it was a separate language .rb-module or something, to make it formal.
- burke 9y agoOh, huh, yeah, that makes sense. That would totally work. Cool idea.
- dragonwriter 9y ago> Right - that's why I said nothing but methods and nested classes - expressions in method bodies would be disallowed. I presume you mean "expressions that aren't method definitions in class bodies" (though that's a problem, because of things like attribute declarations) rather than "expressions in method bodies", since methods with no expressions in their bodies would be pointless.