When BOOL gets into trouble at run-time it throws an Exception. Such problems include resource issues (like a missing file) or code issues (such as when a Model can’t find an Action to handle a received Message).
There are a some native Exceptions, but user code often extends those for the sake of the application (following a common model used in Java, Python, and many other languages).
Strange how my thoughts turn to BOOL in the early part of even-numbered years. (I wonder if it has something to do with the San Francisco Giants baseball team, although I don’t know why, and I’ve been hitting even-numbered BOOL version years longer than they’ve been winning World Series, plus I hope they don’t win this year.)
But in any event, I found myself pondering the
*array type (again)…
It’s been a while since I’ve waded in BOOL waters. As always, there are periods of strong interest and periods — often quite long — of dormancy. Finally solving most of the implementation problems of the language triggered a period of disinterest. That and some uncertainties about exactly how to implement Action Methods, especially the “new” method.
But I recently did have some fun with a
BOOL/OS subsystem, the Message Center Service. I roughed out a crude working version in Python that provides a flavor of the real thing’s architecture.
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.
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.
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?
I think the final piece of the array puzzle finally fell into place. The issue resolved when I last wrote about arrays — whether all data Models have array capability versus arrays being a distinct data model — still stands.
The final piece involves a slight syntax change and — much more importantly — the full rationale for the array syntax. Not really having one was a bother; it made arrays seem arbitrary and patched on. The rationale brings them more fully into the BOOL fold.
BOOL has an
#inline option for Action definitions that allows (but does not require) treating an Action as if it was inserted into the code flow. There is also the idea of native Actions, defined as such by the standard, which are also allowed to be inline.
But a design goal is the ability to implement basic language constructs (such as
if statements and
while loops) in the language itself.
So here are some of those native Actions:
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.