Tag Archives: Actor

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

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 →

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 →

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 →

Actions, part 4

The last topic to cover in this series concerns Action parameters. There are several basic categories of Action parameter; which one is most appropriate depends on how the Action is used. In turn, the category used may have consequences on how the Action is invoked.

The strictest category forces parameters to a specific Model. At the other extreme, the generic category allows any type of parameter. Intermediate categories restrict inputs to a class of types.

Continue reading →

Actions, part 3

At its heart, BOOL has a fundamental principle: Everything is an object. This includes some non-obvious things, such as definitions and even individual statements. In particular for this discussion: statements. For example, in BOOL, an if-else statement is a distinct object.

All statements in BOOL are references to some Action object, which is invoked via an Actor object (Actors perform Actions). In a BOOL program, there can be many Actors that perform a given Action. For example, each occurrence of an if-else statement in the code is an Actor object that invokes the if-else Action.

Continue reading →

Invoking Actions

Finally, a post not filed under Basics!  I’m in a BOOL development mode (they come and go over the years), so more advanced topics are likely. I’m making what feels like excellent progress. Maybe once this phase completes, I can set down to the business of really documenting BOOL here.  (Assuming the development doesn’t end in frustration and tears and I put the whole mess on the shelf for another few years.)

I’ve been mucking about with my Python implementation trying to work my way through an implementation aspect I’ve never been able to see clearly. It has to do with how BOOL invokes code sub-units. We’re talking about “calling” what are variously called: sub-routines, routines, functions, procedures, methods or sub-programs. At least the term “call” is fairly global; in fact, the generic term for these things is “callable unit.”

Continue reading →