Speaking of Names

In the last article I explained where the name, BOOL, comes from. This article concerns the names of things within BOOL.

Languages have various terms for the concepts reified by by the language. For example: “sub-routine”, “function”, “method” and “procedure” all describe the same thing, a chunk of code that can be called by other code. The terminology for data objects is even more diverse!

In part to find the most descriptive words—but also to find new terminology for fun—BOOL has its own terms for the basic concepts.

An Action is the chunk of code mentioned above that can be called by other code (by other Actions). Actions can stand alone, like ordinary procedures, or they can be bound to data, which makes them class methods.

However, in BOOL, a class is called a Model, and Actions bound to a Model are called Model Actions. User code may define new Models or create new sub-Models (sub-classes) from existing Models. In many cases, user code can even modify existing Models. (BOOL does support “final” and “read only” switches.)

System Models provide most operating, file and I/O system resources (in earlier versions of BOOL, they were called Resources). System Models encapsulate memory, network, user devices, displays and files of all kinds. User code may not define or modify System Models, but it may use them as base Models.

Objects are instances of some Model. All Objects are virtual in that they link back to their Model. When you pass a Message to an Object, it passes it to its Model for handling. BOOL “methods” are always virtual.

Models that inherit from, or delegate to, other Models pass appropriate Messages to their parent or members.  Currently BOOL supports only single-inheritance.

Messages are a distinct class of object in BOOL. They are what you send to Objects to accomplish work. Objects usually return some Object (often themselves) in response to a Message.

External Actions (originally called Devices) provide access to external code libraries. The External Action Protocol (EAP) allows you to define external functions and data and how to marshal BOOL data for external calls.

BOOL also has internal native List and Array data types that are not (in the current definition) “owned” by a distinct Model. (These—especially Array—are actually still open topics after all this time!)

The List type, in particular, is a bit odd in that you can use it in an Action to define a received parameter that is a List, but you cannot (at this time) define a new List instance as you can other Objects. You create a new List by simply making a list.

It’s a key topic in BOOL, so I’ll cover it in detail separately.


%d bloggers like this: