Tag Archives: Action

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 →

Advertisements

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 →

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 →

Python Actions

Picking up from the previous post, I want to get into the Python binding for Actions in more detail. I’ve got several examples to help demonstrate various aspects of what the parts of the Action object mean. The design appears solid enough to make it official and move on to the next stage.

Speaking of which: huge milestone in the last few days! The bottom line is that, for the first time, I can generate BOOL objects from a higher-level language. Essentially, I wrote a kind of “macro-assembler” that reads a fairly simplistic language and emits (Python) BOOL objects. It’s a major step in bootstrapping the run-time environment objects necessary as well as providing examples for working on the run-time engine!

It rates its own article soon. For now, Actions ala Python:

Continue reading →

BOOL Python Binding

Again the retirement free time, the pleasure of Python, and perhaps it just being the right time, conspire to move the BOOL project forward into new territory. The Reference Implementation is coming along nicely on several fronts. The design of various objects has become solid enough to use in writing bits of code.

In particular, it’s possible to discuss how objects are represented in Python, and it’s possible to start thinking about the code that works with those objects. With the BOOL source definition becoming more stable, it’s also possible to start thinking about compilers. This post introduces these things; in some cases, in some detail.

For dessert, I’ll briefly mention a BOOL XML binding.

Continue reading →