Autoloading & Autoimporting

When the MillScript compiler encounters an undeclared global variable it automatically attempts to load a matching inventory item. This process is called autoloading, which is short for automatic loading. If there are no inventory items of the same name (excluding file extension, of course) the autoloading fails and an error is reported.

The file name extension, by which I mean the bit that follows the last full-stop in the file name, is used to determine the content type of the file.

  • Files ending ".ms" are MillScript code.
  • Files ending ".tp" are MillScrip XHTML templates.
  • Files ending ".txt" are raw ASCII text.
  • Files ending ".gif", ".jpg", ".png" are the obvious image types. These are not yet implemented.
For each type of file there is a dedicated compiler. For MillScript files the MillScript compiler is reinvoked. For images, a image-proxy compiler is run, and so on. The result of the compilation must be to assign the global variable with an appropriate value - otherwise an error is reported. This is called autoimporting - the process of automatically determining how to import a file into a running MillScript interpreter. The most important case is probably the template compiler whose effect is to bind the global variable to a function. The function will take the same number of arguments as the template. Using a template means applying that function to the right number of actual arguments. In general, you should come to see all these different resource types (images, templates, sounds, etc) as convenient ways of writing MillScript code that define the obvious corresponding data structure. In other words, you could define an image by writing code that looks like this :- 
var image = newList();
image.addLast( { 0xFFFF, 0xA000, 0x0000 } );    # RGB values
image.addLast( { 0xFFFF, 0xA000, 0x0080 } );
image.addLast( { 0xFFFF, 0xA000, 0x0100 } );
... and so on for another 100000 lines
or you could autoload a GIF. The result is the same but the effort expended rather different!

Directory Structure - Inventories

The autoloadable files are put into inventory directories. There is a single shared inventory ${millscript}/inventory and a local inventory for each web site ${millscript}/websites/*/inventory. Both the local inventory and shared inventory are searched, in that order, for a matching filename.

Autoloadable package have their own structure. To write a package openworld.tools, for example, you would create a directory called ${millscript}/inventory/openworld_tools.pkg. Note how the full-stops are replaced by underbars. In this directory, the package loader will look for a file with a matching name i.e. ${millscript}/inventory/openworld_tools.pkg/openworld_tools.ms. When the MillScript interpreter imports this package it unconditionally loads this file.

Furthermore package directories can have their own autoloadable inventories. In our example, the package loader would check for ${millscript}/inventory/openworld_tools.pkg/inventory. If this inventory directory exists it is used whenever trying to autoload the variables of that package.

Autoloadable Maps are represented as directories, too. Let us suppose we had a collection of images we wanted to make available as a Map from strings to Image objects. All we have to do is give the directory with a ".map" suffix and it will be recognized by the Map loader. Each of the files in the ".map" folder will be autoloaded and their results installed in the Map.