Objectsheets

A Simple Object Environment

x-y Function Example

 

Also see: Overview, White Paper, Detailed Trades, References

Generating functional mappings between variables is a fundamental use of spreadsheets. While not sophisticated in an object sense, it will provide our first introduction to Objectsheets. In our example, we will generate a function y(x), where x is between -2 and 2, and y, with y= -3 * x + 5. For this example, we'll use an x increment of +0.5 to keep the size of our Objectsheet reasonable.

First, we create a new pristine Objectsheet via the File > New command. This is what it looks like when created [see the Note on the GUI styling used here].

The Objectsheet is a coherent container of information (both graphical and logical) based around a set of rules that apply to all rows (or "instantiated objects") within (this is akin to a Class in object-oriented parlance). Objectsheets are divided into two parts. The upper part (with the shaded background) is the Template, where all our rules will go, and the lower part (against the white background) is the instance section, where our individual objects and their resulting values will exist.

First, we will describe the Template of our newly created Objectsheet. The title bar contains the Objectsheet name ("Osheet1" by default upon creation). To the right of the Objectsheet identifier is the Show button; with it we will be able to display and hide other constituents of the Template. These other parts of the Template will provide additional control over the definition of the objects in this Objectsheet. We will come back to it later.

The second line in the Objectsheet here is the only other portion of the Template viewable by default; it is the property-name row. For our example, we now name our properties by running a spreadsheet-like box cursor over the first two property headings, and replacing them with "x", and "y", respectively (in this case, objects will be anonymous, individual object names will not be entered on each row). The result is shown below. We'll also enter a name for our Objectsheet, function1, by double-clicking on the title bar and entering that name.

We get rid of the Property3 and Property4 columns since we don't need them. A simple way of doing this is to highlight each column's headings, right click (or go to the Application's Edit menu), and select Delete.

It will be useful as well to see explicit row numbering. From the Show button, we show the index column [see the Note on zero-based indexing]. (note that it is possible that the index can be made the default first column, with the column numbers 0, 1, 2... replaced with object names as the user sees fit.)

There are actually 3 different ways to enter formulas. We will introduce them one at a time. The first approach is very similar to that used in a spreadsheet. We simply type in an initial value for x in the first row, and replicate an increment formula to increase its value for the succeeding rows.

Note that the formulas, while easily understood, are a little different than typical spreadsheets. The figure below shows the first entered formula, before hitting the return key

Some explaination of our syntax is in order here. The focal point for all referencing in the Objectsheet is the object itself, corresponding to an entire row in the sheet. In Objectsheet parlance, the object called this refers to the current object (that is, "the row currently being evaluated"). Another convention, this[·], implies a relative reference, where the value in the brackets is simply a row offset to the current row. In this example, this[-1] refers to the row immediately above ("this row minus one") (this will look familiar to those that have used the R[·]C[·] reference model in a traditional spreadsheet instead of A1, B2. Note that R[·]C[·] is rarely used in spreadsheets for its own reasons-- absolute refencing, like R47C28 is ugly and difficult to comprehend).

Once we have a reference to the target object (row), we pick off the desired property, in this case, x. This is done with the syntax {Object}-dot-{Property}. In our case, the reference is this[-1].x, and refers to "the value of x in the row immediately above" (note that the reserved word prev is synonymous with this[-1], but was not used in this example).

Even though this syntax uses a relative reference akin to that used in spreadsheets, the referred-to property, x, is not relative, but explicitly named. This allows even relative references to contain meaning. this[-1].x means directly, "the value of x in the row immediately above" (in fact, a great majority of relative references we encounter in spreadsheets are to the "immediately previous row").

Contrast relative referencing in Objectsheets to the analagous formula in a traditional spreadsheet, "=A1+0.5", which requires us to make the additional cognitive jump, "Column A refers to x". This is the primary difference between the Cartesian referencing of spreadsheets, and the Object-based referencing of Objectsheets.

Next, we enter our formula for y. We type in the formula at row index 0.

For references within the same object (row), we can omit the this construct and directly access the property. Property-based references within the same object are absolute (within the object) and therefore named. We replicate each column down (via copy and paste, or a canned "fill down" command) to fill in the rest of the formulas.

We now have our mapping between x and y. The approach we've used here is perfectly valid within the Objectsheet model and is very similar to traditional spreadsheets. Nevertheless, it suffers from some important limitations. First, formulas are hidden; one can see only a single formula at a time (in the formula bar, which was not rendered here). Alternatively, one can choose to show all formulas, but then the cell values are hidden. Second, changing a replicated formula is a multi- step process; after changing the first formula, it must be replicated over all rows.

The second of our three approaches uses the Objectsheet Template's formula row. This approach marks a larger departure from the traditional spreadsheet model. We start as above, with our already labelled Objectsheet. We show the formula Row via the Show button.

Showing rows in the Objectsheet Template automatically brings up the index column. The formula row contains default formulas for all objects (rows) in the sheet. Here, we enter our formula in one place; once we hit enter or leave the cell, all Objectsheet entries (as well as any references to them) are immediately updated to reflect the entered formula.

Our Objectsheet has an error-- we have created a relative reference without a starting value. For row 0, the expression "this[-1]" wants to access "the row at index -1", which does not exist on the sheet. The Objectsheet calculating engine therefore reflects and propagates this unknown reference. To fix this error, we will override the x value of the object at row index 0. When the calculating engine finds an override in that cell, it uses that formula to fill in the cell and skips the Template formula, moving on to the next calculation. By giving x in row 0 an explicit value (-2 in this example), the formula will have what it needs to correctly reference the remaining cells. We also place the formula for y in its Template location.

Note the blue bar. This is an override indicator. Since the Objectsheet is aware of Rules (from the formula row in the Template), it is also aware of exceptions (or overrides), and can flag them, as it has here with the blue bar. The result is that we are much less likely to generate errors by forgetting which cells have which formulas and which were manually changed. Note that since cell formulas in traditional spreadsheets have only one context (cells)- there are neither "rules" nor "exceptions", only cell formulas.

We can expand rows to create more instance variables values by using the pull-down bar (the brown horizontal bar, shown only in this rendering, but a generic component of Objectsheets) to add the desired number of rows. We have defined the entire set of cells with only a few actions, and the formulas exist in a single place (there has been no replication). Changing a Template formula on the Objectsheet requires one action: modifying the formula itself; there is no longer the need to explicitly replicate a formula to all its instances.

In the third version of our example, we capture the initial condition in addition to the replication within in the Template formula itself. The y property formula remains as before, and we modify the x formula thus:

The initial condition is captured via the Javascript (from C) ternary conditional expression. It is actually identical to the if({condition}, {true formula}, {false formula}) found in traditional spreadsheet syntax. This additional complexity completely eliminates cell overriding. The object structure is formed completely within the Template (i.e. by only Class-level definitions). This will be important when we clone and subclass Objectsheets.

In this introductory example to Objectsheets, we have introduced a number of its core concepts.

Note that in this example, we have used only relative references. Absolute references are even more direct, with "object.property" notation, using both row heading and column heading explicitly.

In our 3 example implementations, we have gone from a familiar, spreadsheet-like implementation of our problem, requiring several steps, to an implementation requring only three steps. While the Objectsheet can be treated very much like a traditional spreadsheet, it's power lies in a different model: the object-oriented. As a given problem grows in complexity,

We have also provided a fundamental constraint to the traditional spreadsheet; that is, in a single Objectsheet, columns have a singular purpose defined by the property's and class's rules (although individual cells could be overriden to the user's whim). The freeform character of the spreadsheet is strong primarily within a single "table structure". Relationships across different tables wthin a spreadsheet are much more cumbersome, and especially if the cartesian relationships change between them. The object-based structure of the Objectsheet allows much stronger and simpler associative referencing between Objectsheets, and should therefore make them easier to use and understand.

Future examples will focus more on a more sophisticated data structures, we will also explore inheritance between Objectsheets.

Notes

Please press your browser's Back button to return to your place in the text.

  1. Javascript Engine The Objectsheet analytical engine is currently assumed to be Javascript, although that point is still open to trade. All developed syntax is consistent with the language, although there are reserved objects, like "this", that are reserved within the Objectsheet structure.
  2. GUI Styling For clarity, minor details of the GUI are missing (like window resize and go away/minimze boxes, a formula bar beneath the application's menu bar, and the like.
  3. Property Names In this example, the property names are very simple (x and y). For more sophisticated cases, we will want longer, more descriptive property names, and possibly names different from those visible as column headings. In fact, property names are distinct from the property column headings; the reference names are generated from the headings via a set of rules and are hidden by default. See the Detailed Trades for more discussion on this.
  4. Zero-based Indexing In this example, the index column starts at zero. In the development of this application/framework, we are striving to balance appeal to the lay-user and the power-user, and have to continually concern ourselves about the orientation of each feature. The fact that the row index starts at zero implies appeal to the programmer, since starting to count from 0 is generally not intuitive. See the Detailed Trades for more discussion on this.
  5. ThisIndex reserved variable The thisIndex keyword refers to the index of the current row. We refer to the object immediately above (by 'thisIndex-1', a relative reference), get its x property, and add our increment of 0.5.

 

Also see: Overview, White Paper, Detailed Trades, References

rk, 4 July 1999
email author