Satellites provide a way to associate arbitrary textual information such as names and expressions with Chipndale instances and Chipndale cells. This document describes all users need to know about satellites in order to use them.

Satellites come in two flavors: instance and object. An instance satellite is a Chipndale text instance that has been associated explicitly with another (non-text) Chipndale instance called the satellite's master; a master along with its satellites is called an instance group. An instance group exists in a world, which is a list of Chipndale instances that is either the contents of some Chipndale cell or of the top level of the design. Any text instance that has not been associated explicitly with another Chipndale instance is an object satellite. The object to which an object satellite is bound is the container of the world in which the satellite exists—if the text is inside a cell then the container is the cell; if the text is at the top level of the design then the container is the design. Object satellites along with their host object (if any) are called an object group. Either flavor of satellite can be marked to be a comment, permitting it to be ignored if desired.

A useful model of satellites is that they are visible properties attached to a master or to an object. However, there are three important differences between satellites and properties: First, satellites are always visible, while a user must do something explicit to display properties. Second, the user has complete control over the looks and placement of satellites, while properties are displayed in a fixed way. Finally, satellites are simply text strings; this is in contrast with properties, which have type information associated with them.

The association between a master and its satellites is made via a special groupIdProp property attached to each. The value of this property is an integer that is unique (within the design) to the instance group in question. This method of associating group members is convenient for interactive purposes, but unfortunately is not sufficient for a reasonable programming interface. The problem is that in order to find an instance's satellites we need to know the world in which these satellites exist. For some applications carrying around the world is inconvenient, so it behooves us to provide a way to find an instance's satellites given just the instance. This more convenient way is provided by putting a satellitesProp property on the master, which has as its value the list of text instances that are the master's satellites. (If you're wondering why just having the list of text instances alone does not suffice see Appendix A.)

Satellites satisfy a number of invariants which may be taken as defining properties:

The programming interface provides procedures to add, remove, and retrieve satellites from a given master. A final procedure allows clients to guarantee that the defining invariants are preserved after manipulation.

CDSatellites is part of PW. So, to run CDSatellites you need to do the following:

The current version of satellites has gone through a number of redesigns and reimplementations as deficiencies were discovered and fixed, and several people have contributed their ideas and time. An initial implementation was by Louis Monier. A complete redesign was done by Bertrand Serlet and Pradeep Sindhu, followed by several iterations over this design. It took one more complete redesign and reimplmentation (by Pradeep Sindhu) to get to the current version.

There are two problems with just having a list of instances that records a master's satellites: the first takes a small matter of programming to fix, while the second is basic. The SMOP problem is that properties that have Cedar LIST's as values cannot be written out to Chipndale files. The basic problem is that Chipndale instances are not permanent entities—they can disappear and be replaced by an identical instance at any time (well, not any time, but you get the idea). Therefore we cannot cache REF's to instances.