Objects

An object is a BLOB, which is a sequence of bytes. The object may be categorized by how the object comes to exist:

• a "generated" object created by a form
• anything else is an "input" object. For example, a file in your project may be an "input" object.

But to re-iterate: There is no concept of an object being a "file" or a "directory". The object is just a sequence of bytes.

In both cases the build system treats the objects as immutable, and the objects may be cached and/or persisted to disk whenever necessary.

When a value shell command is being run (described in the upcoming Value Shell Language section), an object is made available on disk. At this time an object is "realized" into either a file or a directory. That is the subject of the next Saving and Loading Objects section.

Design Note: Why blur the distinction between files and directories? These objects are meant to be cloud-friendly so they need to have a canonical representation on cloud value stores like AWS S3. We don't need strict typing everywhere! And using a compressed archive means accessing the multiple outputs of a form function is quite straightforward; in contrast, other build systems expose the user to added complexity (confer: make: Handling Tools that Produce Many Outputs).

Saving and Loading Objects

When a value shell command reads an immutable object and saves it to a file (ex. get-object -f FILE), the bytes of the immutable object are copied directly to the file.

When a value shell command reads an immutable object and saves it to a directory (ex. get-object -d DIR), the bytes of the immutable object are:

• when the bytes have a zip file header uncompressed and unzipped into the directory
• when the bytes do not have a zip file header copied into the directory in a file named OBJECT

When a value shell command saves a file as an immutable object, the file's bytes are saved as-is.

When a value shell command saves a directory as an immutable object, the directory is zipped and the zip archive bytes are saved. The standards of Zip Archive Reproducibility will be followed.

That sounds inefficient, but the build system is allowed to optimize a set of value shell commands. For example, if one shell command saves output into a directory, and a second shell command reads data from created by the first shell command, the build system can give the second shell command a symlink to the first directory without using a zip archive as an intermediate artifact.

Object Slots

Each object has one or more slots. Each slot is a container for the object's files.

There are no built-in slots. However, Release.Agnostic is the conventional slot for files that are ABI-agnostic.

The names of the slots are period-separated "MlFront standard namespace terms". Each of these terms:

• are drawn from the character set 'A' .. 'Z' | 'a' .. 'z' | '0' .. '9' | '_'
• must start with a capital letter
• must not contain a double underscore (__)
• must not be a MlFront library identifier (ie. a double camel cased string followed by an underscore and another camel cased string, like XyzAbc_Def)