Javascript – Looking for a way to handle Javascript file dependencies

Should I pass the Graphics to the Draw() function?

Well, when I saw this design, first thing which came into my mind was "why the heck does the TextBlock have a Graphics attribute at all? Should it not be possible to draw the same block on two different graphics contexts? Should the TextBlock object not have a lifetime which may be longer than the lifetime of the Graphics object?"

So my answer is yes - it does not make much sense to me not to have a Graphics parameter in the Draw function. This will imply to pass the Graphics parameter into the DrawBlocks method of the Page, and some other method in your Section, of course, but that is probably the correct design.

In fact, when your TextBlock has more than a half dozen private methods, all called directly or indirectly from Draw, and all of them use the same Graphics object, it may be more convenient to buffer the Graphics object passed by the Draw method in a member variable, so you do not need to have the same Graphics parameter in all of those methods. So keeping this attribute as a member might make sense (but this cannot be deciced from the small part of the text block class we see in your current model). And if you decide to keep this attribute, make sure you add a comment when this attribute is set and how long it is valid. The code then will look like this

   void Draw(Graphics g)
   {
      graphics=g;
      // ...
      // call some members depending on "graphics"
      // ...
      graphics=null; // just in case, to avoid accessing an invalid graphics object
   }

Alternatively, you could consider to introduce a helper class TextBlockDrawer, which gets the Graphics object and the TextBlock passed as a constructor parameter, and encapsulates the whole drawing process. That way, you won't need a Graphics member in your TextBlock class any more, only in TextBlockDrawer, and this attribute can be initialized in the constructor of that class. This design also makes a better separation between the data (TextBlock) and the drawing process. The resulting code will look either like this:

class TextBlock
{
   public void Draw(Graphics g)
   {
      var tbDrawer = new TextBlockDrawer(this,g);
      tbDrawer.Draw(); 
   }
}

or, by omitting the Drawmethod in the TextBlock completely, and reuse the TextBlockDrawer for different text blocks:

class Page
{
   // ...
   public void DrawBlocks(Graphics g)
   {
      var tbDrawer = new TextBlockDrawer(g);
      foreach(var tb in MyTextBlocks())
          tbDrawer.Draw(tb); 
   }
}

In situations like this, when I have one part of my program that needs to stand alone as a single, self-contained module but contains many thousands of lines of code, I prefer to take a compositional approach to keep things clean and manageable.

Instead of trying to keep all of your functionality in one class, why not break it out into several "internal" classes that your main VirtualMachine class instantiates in its constructor and delegates to? Each class would be in its own file, and you can give your VirtualMachine class a facade interface to abstract the fact that it delegates to multiple objects internally to do what it needs to do (i.e. you can keep its interface the same as it is now even though its functionality is broken up into multiple classes internally).

I know you said that it makes sense for all of the code in question to be in one class, but even so large classes often have discreet subsystems that are responsible for specific things. Maybe the examples you provided (Stream, Style, Window, etc) handle specific concerns in your larger VirtualMachine class? In my opinion it's fine to break these out into separate classes that are only meant to be instantiated and used together in your main class.

If your classes all need access to some shared state, break that out into a separate class as well, instantiate it in the VirtualMachine class constructor, and pass it to all the other classes via their constructors when you create them.

The main benefit of taking this approach over the others you mentioned is that it can be done with a simple and well-understood language construct (a class) and common design patterns (delegation and composition), instead of relying on build magic or esoteric language features to work.