C H A P T E R 1 1
Data Storage and Retrieval
About Data Storage on Newton Devices
11-3
lookup, message-passing, and inheritance in NewtonScript, see The NewtonScript
Programming Language
Programming Language
.
Other than the requirement that data must reside in a slot, frames don't impose any
structure on their data. In practical use, though, the slots in a frame tend to be
related in some way, usually holding related data and methods which operate on
that data. In this way, the frame exemplifies the classic object-oriented
programming definition of an "object." Frames do not implement data-hiding,
however, nor do they necessarily encapsulate their data.
structure on their data. In practical use, though, the slots in a frame tend to be
related in some way, usually holding related data and methods which operate on
that data. In this way, the frame exemplifies the classic object-oriented
programming definition of an "object." Frames do not implement data-hiding,
however, nor do they necessarily encapsulate their data.
RAM-based frames are not persistent until they are saved in a data structure called
a soup, which is an opaque object that provides a persistent, dynamic repository
for data. Unless removed intentionally, soups remain resident on the Newton device
even when the application that owns them is removed.
a soup, which is an opaque object that provides a persistent, dynamic repository
for data. Unless removed intentionally, soups remain resident on the Newton device
even when the application that owns them is removed.
The only NewtonScript object you can save in a soup is a frame; recall, however,
that any slot in the frame can hold any NewtonScript data type and multiple data
types can reside in a single frame. The object system does not impose any
limitations on the number of frames or the kinds of data that may reside in a soup.
In practical use, though, the items in a soup generally have some relationship to
one another.
that any slot in the frame can hold any NewtonScript data type and multiple data
types can reside in a single frame. The object system does not impose any
limitations on the number of frames or the kinds of data that may reside in a soup.
In practical use, though, the items in a soup generally have some relationship to
one another.
Soups are made available to the system in a variety of ways. Applications may
create them on demand, they may be installed along with an application, or the user
may introduce them by inserting a storage card in the Newton device.
create them on demand, they may be installed along with an application, or the user
may introduce them by inserting a storage card in the Newton device.
The soup resides on a store, which is a logical data repository on a physical storage
device. A store may be likened to a disk partition or volume on a conventional
computer system; just as a disk can be divided logically into multiple partitions, a
physical storage device can house multiple stores. The Newton platform supports a
single internal store and one or more external stores on PCMCIA devices.
Applications can use as many soups as they need, subject to the availability of
memory space on stores and in the NewtonScript heap.
device. A store may be likened to a disk partition or volume on a conventional
computer system; just as a disk can be divided logically into multiple partitions, a
physical storage device can house multiple stores. The Newton platform supports a
single internal store and one or more external stores on PCMCIA devices.
Applications can use as many soups as they need, subject to the availability of
memory space on stores and in the NewtonScript heap.
Each store is identified by a name, which is not necessarily unique, though each
store has a nearly unique random number identifier called a signature. The store's
signature is assigned by the system when the store is created.
store has a nearly unique random number identifier called a signature. The store's
signature is assigned by the system when the store is created.
Soups can reside on internal or external stores; a special kind of object, the union
soup, represents multiple soups as a single entity, regardless of their locations on
various physical stores. For example, when a PCMCIA card is installed, application
data may be distributed between the internal and card-based soups. The union soup
object provides a way to address multiple soups having the same name as a single
"virtual" soup. Figure 11-1 illustrates the concept of a union soup graphically.
soup, represents multiple soups as a single entity, regardless of their locations on
various physical stores. For example, when a PCMCIA card is installed, application
data may be distributed between the internal and card-based soups. The union soup
object provides a way to address multiple soups having the same name as a single
"virtual" soup. Figure 11-1 illustrates the concept of a union soup graphically.
It's important to understand that there is only one kind of soup object in the
system; a union soup object simply represents the logical association of multiple
soup objects. In other words, aside from their logical association with other soups
in the union, a union soup's constituent soups (also called member soups) are no
system; a union soup object simply represents the logical association of multiple
soup objects. In other words, aside from their logical association with other soups
in the union, a union soup's constituent soups (also called member soups) are no