Reduce surface area

[perimosocordiae]

In the spirit of trying to modularize Doppio, I've come up with a list of points that we currently reach into the core library:

• disassembler.dissasemble
  • wrap current class in call to new ReferenceClassData(buff)
• util.BytesArray, util.bytes2str, util.int_classname, util.last
• jvm.*
  • ClassLoader
  • RuntimeState
• testing.run_tests

The items under jvm are ones that we can roll into a (hopefully) upcoming JVM object. This can manage the classpath, the bootstrap classloader, and the creation/management of the runtime state.

[perimosocordiae]

The public interface for Doppio now looks like:

import disassembler = require('./disassembler');
import jvm = require('./jvm');
import logging = require('./logging');

// Function that takes a classfile buffer and emits disassembly as a string.
export var disassemble = disassembler.disassemble;

// Class that encapsulates the entire JVM.
export var JVM = jvm.JVM;

// Set of values for controlling how much logging is emitted.
export var log = {
  level: logging.log_level,
  VTRACE: logging.VTRACE,
  TRACE: logging.TRACE,
  DEBUG: logging.DEBUG,
  ERROR: logging.ERROR
};

I'm not sure what the best way to expose this is. Perhaps make a main.ts file with these contents and use that to generate the full doppio.js library? Or just craft a doppio.d.ts with this information?

Our console and browser frontends actually use slightly more than what I've listed above, but those cases are either temporary hack-arounds or development-specific (i.e., testing) code.

[jvilk]

The following would probably be best:

• Craft a doppio.d.ts with that information.
• Reference doppio.d.ts from within our codebase, and specify that particular components implement the interfaces specified in the file.

It would result in us duplicating the type annotations across the two files, but maybe that's a Good Thing; it forces us to know when we make breaking API changes.