Special-Purpose Objects for Data Storage and Retrieval

About Special-Purpose Storage Objects

in a local soup. Your mock entry could reside in a mock soup, which, in turn, could
reside on a mock store.

The mock entry counterparts to the system-supplied EntryXxx functions are
implemented as the methods of a NewtonScript frame known as the mock entry's
handler. You supply this frame, which implements these methods as well as any it
requires for its own purposes. The handler may also hold information local to a
specific mock entry or information required to retrieve the mock entry's data.

Like a normal soup entry, the mock entry caches its data in the NewtonScript heap
when the entry is accessed; thus, the data associated with a mock entry is called its
cached frame. As with normal soup entries, the cached frame appears to be the
mock entry itself when accessed by other NewtonScript objects. Your handler
provides an

EntryAccess

method that creates this frame in response to messages

from the system.

The cached frame must be self-contained, just as a normal soup entry is. Therefore,
the cached frame must not use

_proto

and

_parent

inheritance.

To create a mock entry, you call the

NewMockEntry

global function. Depending

on your needs, you can create the mock entry with or without its associated cached
frame. Either way, the mock entry object returned by this function manages other
objects' access to its cached frame.

When the mock entry's cached frame is present, the system forwards entry
accesses to it transparently. When the cached frame is not present, the system calls
the handler's

EntryAccess

method to generate a cached frame before forwarding

the access. You must supply this method, which creates and installs the cached
frame in the mock entry.

The handler's

EntryAccess

method is called only when a slot in the mock entry

is accessed. Simply referencing the mock entry does not cause the cached entry to
be created. For example, in the following code fragment, assigning

m

to

x

does not

create a cached entry--it just creates another reference to the mock entry. However,
accessing the mock entry's

foo

slot from either of the variables

m

or

x

may cause

the

EntryAccess

method of

myHandler

to be invoked.

local myHandler := {

object: {foo: 'bar},
EntryAccess: func (mockEntry)

begin

// install cached obj & notify system
EntrySetCachedObject(mockEntry, object);
// return cached obj
object;

end,

// your additional slots and methods here
...}