"Immutable" Values Gotcha

Table values are immutable, so sometimes you have to make copies values

Example workspace: "Immutable" Values Example Workspace

In Apogee, the value of a table is immutable, meaning you can't modify it once it is set. Well, you can always edit the workspace, but you can not modify a remote table from within a calculation. This example project illustrates exactly what this means.

The example workspace contains three tables (and the notes table):

• coordinates - This holds a manually defined array of coordinate pairs.

• badModifiedCoordinate - This table takes one of the coordinate pairs from the coordinates table and tries to modify it. This throws an error because modifying the coordinate pair as is done here would also modify the value of the coordinates table. The error message says "Cannot assign to read only property..." because the value of the coordinatestable is read only once it has been set.

• goodModifiedCoordinate - This table does the same thing as the table badModifiedCoordinate except it first makes a copy of the data before it modifies it. In this case, modifying the copied data does not attempt to modify the coordinates table. The return value from this copy function is not read only, so we can change its value.

The reason Apogee works this way is that once you make a change to the workspace, Apogee internally determines the order in which it must calculate the table values so that every table is calculated before it is used in the formula of another table. If one table could be modified during the calculation of another table, then the determination of the order to calculate tables would be impossible (or at least a lot harder).

Another way to say this rule is that there are "no side effects". We don't want the calculation of one table to affect the values of the other tables. This is a tenet of functional programming, and sure enough, Apogee is a form of functional programming, just like a spreadsheet.