Monthly Archives: July, 2014

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.

Continue reading →

Advertisements

Binding Instances and Models

There is a design choice involved with regard to how Instance objects are bound to their Model object. A similar choice exists concerning Actor objects and their Action objects. (Actors can be called “instances” of an Action.)

The choice is between a BOOL-like design where the Instance sends a message to the Model, or an implementation design that lets the Instance directly call the Model. This post documents the two choices and the resolution to use the latter.

Continue reading →

Singleton Messages and Actions

A recommended idiom involves defining Actions to implement Singleton Messages. This cleans up source code by removing the need to use the semi-colon, and shifts possible “Unknown Message” errors to data type errors, some of which can be detected at compile time.

Continue reading →

Action Walkthrough, part 4

While not really part of the Action walk-through, per se, the sequence of events involving Messages still involves Actions, because Model Actions implement message behaviors. Therefore, nearly all messages ultimately result invoking some (Model) Action.

This article details the sequence of events involving Message objects.

Continue reading →

Action Walkthrough, part 3

The discussion of how an Action works continues with a detailed list of Action start-up events. The example code for the Action under discussion is shown in the first article.

Continue reading →

Action Walkthrough, part 2

There are two protocols for invoking Actions that are under consideration. Both are described here. The example code for the discussion was shown in the previous article.

Continue reading →

Action Walkthrough, part 1

This post series explores an Action in detail with emphasis on the Instance objects, especially the dynamic (temporary) ones. Posts are broken up mainly for size considerations.

Continue reading →

Temporary Objects

One of the final hurdles in designing a BOOL implementation involves temporary objects. Any operation on an object may result in a transitory new object that is consumed by later operations. For example, in the arithmetic expression “5 x (3 + 4)” the addition operation creates a transitory value — 7 — required by the multiply operation.

The question for an implementation is, “Where to store such temporary objects?” In some languages, CPU registers suffice to store transient values (such as seven), but in object-oriented languages, registers aren’t enough. Objects take up some space, and often temporary objects need to be addressable.

Continue reading →

Casting Values

There is the situation when an operation takes multiple operands, and one (or more) of those operands are inappropriate for the operation. For example, suppose an integer add operation was passed an integer object and an open file object? There is generally no “add” semantic for an integer and a file.

Total incompatibility results in a run-time error, but sometimes values are compatible enough for the operation to proceed. How the system accomplishes that often involves casting one value into another.

Continue reading →

Pass by Value

One language question designers need to address is whether objects are passed by value or by reference when invoking callable objects. It’s common in object-oriented languages to pass by reference to avoid having to build copies of passed objects.

BOOL uses pass by reference, which begs two questions: Do we provide a means to pass by value when desired? And if so, which side — caller or callee — can do the magic?

Continue reading →