ClassLibrary object in VM

[jjfiv]

The ClassLibrary will be the object within the VM that contains all the classes defined.

VM::defineClasses will call this._classLibrary.defineClasses

The convoluted searching for a main class will be partially replaced by ClassLibrary::findClassByName(name: string), as that will be a common operation.

We should probably also support a findClassByType(type: Type) which asks the type for its name and calls that other one.

We will need to expand on the class library as the need arises.

[jjfiv]

It should also complain if you define a class that's already defined. Or merge them? I'm not sure if that would always be possible.

[etosch]

So is ClassLibrary anything like the JVM's ClassLoader? And these are classes that are available to all threads?

Would this then be a refactoring of the code found here? If so, do you think this is a fairly contained task?

[jjfiv]

This is half of that refactoring. The other half is in Issue #52.

Sort of like a ClassLoader, except I really don't know much about ClassLoaders. I doubt we will support responding to requests to load a class on demand. Either we have it via a dex or not.

[etosch]

Just pushed the code. Can everyone pull and make sure index.html and mock-hello.html are copacetic? Is this issue ready to be closed?

The format of the thing is a an object with one field that is a hashmap where keys are type names and values are class objects.

Regarding my commit, should the propagation of the mains into the selector thing happen in Upload? I was thinking it should, since that's handling interaction between the VM and the browser.

[jjfiv]

index.html & mock-hello.js seem good to me.

Regarding my commit, should the propagation of the mains into the selector thing happen in Upload? I was thinking it should, since that's handling interaction between the VM and the browser.

Totally. Feel free to add a classChooser object to the VM and fill it out appropriately. Eventually we should filter to classes that have main defined, but if we want to just stick every class in there for now, there's no problem with that.

[etosch]

Should the classChooser object really be a field of the VM or of the Upload object? Since the upload object is a field of the VM, I feel like it ought to be mediating the interaction.

[jjfiv]

Totally your call. It could even be a field of the ClassLibrary object. However you want to implement it.

[etosch]

in VM.js, should _classList in VM::start now be a classLibrary, or a subset of classes only used by the main class (and will these things even be different?)

[jjfiv]

_classList isn't really needed unless we want to keep it as a convenience. Everywhere we'll need to update:

vm.start(classes, "mainName");

with

vm.defineClasses(classes);
vm.start("mainName");

[etosch]

Ready to close?

[jjfiv]

This is ready to be closed. I foresee some future changes needed, but definitely good for now.