Terminology and Abbreviations

The purpose of this page is to define abbreviations and terminology used throughout the PluginPlay documentation. Terms and abbreviations are listed in alphabetic order. Other pages are encouraged to link to the terms and abbreviations.

Terminology

Bound Input

For a particular Module, M, an input k is said to be bound if the ModuleInput instance returned by M.inputs().at("k") has a value. When a Module is called as a particular Property Type, all inputs not appearing in the definition of the Property Type must be bound.

Bound Submodule

Same as a Bound Input except that it refers to one of the submodules that a module will call instead of one of the input options.

Field

A term for generically referring to the arguments to/from a function, i.e., both inputs and results are fields.

Locked

A Module is said to be locked if the end-user accessible state can no longer be changed. This occurs when a Module is run and prevents concurrent access from invalidating Memoization.

Memoization

A technique where repeated calls to an expensive function, with the same input, are avoided by saving the input to the function, and the result of calling the function.

Module

Self-contained pieces of code. Modules wrap developer provided code in a common API that can be used by the rest of PluginPlay.

Opaque

The opposite of Transparent. An option is “opaque” if changing its value changes the result of a Module.

Plugin

These are groups of Module that are distributed together. In C++ plugins will be libraries, whereas in Python they will be Python packages.

Property Type

A property type is a domain-specific quantity of interest. For example if your code computes geometric properties of shapes then you may have property types for area, volume, and perimeter. Basically these are the quantities that users of your code will want to compute and they define the API for calling a Module which can compute the namesake property.

Strong Type

In C++ a strong type U is a class which wraps an object of type T so that it has a different type than other objects of type T. This is mainly used when arguments to a function have the same type, but different meanings. For example, consider:

void draw_box(float length, float height);

Accidentally passing the height as the length and the length as the height rotates the box by 90 degrees. Since both arguments are float there is no way for the compiler to know you messed up. If we instead do:

struct Length{ float value; };
struct Height{ float value; };

void draw_box(Length length, Height height);

It becomes much harder for the user to swap the length and height accidentally because they now formally have different types. It should be noted that most modern compilers can optimize the additional indirection out so the use of strong types should have little to no performance overhead.

Submodule

A Module called from within the body of a Module. In most cases the “sub-” prefix is simply to discern the caller from the callee. The notable exception is when discussing the Submodule class, which defines the interface for how the caller will call the callee.

Transparent

An input to a Module is “transparent” if the result of the Module does not depend on the value. Most inputs are Opaque in that their values do change the resulting value. Examples of transparent options include debug printing levels and options that affect the speed at which an algorithm computes (block sizes, number of threads, etc.), but not the accuracy.

Abbreviations

API

Application Programming Interface. The literal functions you call to programmatically interact with a software package.

PIMPL

Pointer to IMPLementation. A common C++ technique used to separate the API of the class from its implementation. The API of the class is declared in an “outer” class. The outer class has a (usually private) member which is a pointer to an “inner” class. The inner class holds the state and implementation. Since the outer class holds a pointer to the inner class, it suffices to forward declare the type of the inner class, in turn avoid the leakage of details needed to power the inner class.