Implementing “new”

One of the last hurdles involves the implementation of the new behavior. Models manage Instance value objects and provide new data objects (used by Instance objects to populate Call Frame slots). Model objects must provide an API to support creating and destroying Instance objects as well as manipulating their value objects.

The basic question is what to do about the data definition in Model objects. Does the meta object need a copy of a “default” Instance object? The syntax allows initialization lists for member objects. This implies some activity — either copying or initializing — when a new object is created, especially a user-defined object.

Consider this user-defined Model:

**point
.   *float x = 0
.   *float y = 0
.

The Model defines two members, both *float Instance objects, and names them x and y. This new Model makes it possible to declare *point Instance objects:

*point  P1
*point  P2 = 0,0
*point  P3 = P2

A *point Instance is a user-defined object, so its structure is a list of its data members as defined in the Model. In this case, a “point” is a list of two *float Instance objects. The question is, how does the Model build a new Instance?

A side question involves where code for creating new objects goes. Model behaviors are implemented in Actions, and each Action has a codeblock.  That means the code for all Model behaviors is in its Actions. (Model objects themselves don’t have a codeblock.)

The answer seems to be implicitly creating a new Action to build the new Instance object. (Note that the code object always pre-exists in code as an INST or TEMP Instance object. The Model only creates new data objects and value objects.)

The implicit new Action would make it look as if the code was actually:

**point
.   @@new
.   <<  *list p
.   .   *float x = 0
.   .   *float y = 0
.   .    a:p x
.   .    a:p y

The a: (append) message is a System Message used to add items to a list, but both the @new Action and the a: message are virtual. In fact, the Model meta object implements the new behavior as-if the code looked something like the above. (Obviously, the actual members would vary for different Model definitions.)

Native Models manage the new and destroy behaviors internally.

The Model meta object, and any Native Model meta objects, implement this API:

  • new_object()
  • destroy_object(data-key)
  • get_value(data-key)
  • set_value(data-key, new-value)

The first creates new data and value objects and returns the data object. The second destroys the value object associated with data-key. The last two access value objects given some data-key.

Advertisements
%d bloggers like this: