A user-defined Opus variable is identified by its
fully-qualified name, such as urbansim.gridcell.population. The
fully-qualified variable name encodes three pieces of
information: the package containing it (e.g., urbansim), the name of
the dataset to which this attribute belongs
(e.g., gridcell), and the un-qualified name of the variable
which is unique within that dataset (e.g.,
population). Using fully-qualified path names explicitly indicates where
each variable's definition comes from. (In retrospect, this may not be
ideal, and in the future we may no longer require the package name as part
of variable names.)
The similarity to a Python import statement is not a
coincidence: Opus uses an import statement to load the variable's
definition.
The un-qualified part of an Opus variable name may specify
a ``template'' that matches a family of related variables.
The variable
mypackage.mydataset.number_of_SSS_projects_within_DDD_meters, for
instance, matches
mypackage.mydataset.number_of_residential_projects_within_500_meters
as well as
mypackage.mydataset.number_of_industrial_projects_within_1000_meters.
When Opus looks for the definition of this variable, it
matches any SSS to strings of alphabetic characters and underscores,
and any DDD to integers. These values are then passed to the
variable code, allowing it to modify its behavior according
to the specified values. When there is an ambiguity, Opus will issue a
fatal error.
Opus variable names must be lower-case, except for any
SSS and DDD pattern makers. This reduces the change of
problems with incorrect case, or with migrating Opus code between operating
systems that are case-sensitive and those that are not.