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.
There was meant to be a third article in the Native Objects series that would discuss the Actions (“methods”) supported by the native Models (“classes”). But I’ve only begun to define those things. For now, suffice to say that typical data types (integers, floats, strings, etc.) have the methods you’d expect. Assignment for all, basic math for the numeric types, stringy stuff for the string; you get the idea.
I’ve reached another major milestone, but I’m also about to begin another design phase as I figure out exactly how to implement the native Models. And I may be taking a break from this blog to give BOOL a rest and to deal more with other matters.
Languages generally come with two distinct sets of features: native objects and library objects. The former are often built into a language, for example
float in the C-family languages, or
The lack of distinction is more common in object-oriented languages, and BOOL is not exception. Native types “look” identical to user-defined types; operationally they are identical. The next few posts discuss BOOL’s native objects.
Picking up where I left off regarding run-time sub-systems, there are a few more to mention. In a stripped-down version of BOOL, these sub-systems could be stubbed out, but proxy agents would still have to represent them. All the sub-systems discussed in these two articles are required to be present, but not all are required to be functional.
Obviously, non-functional sub-systems still accept Messages and respond appropriately, if only to signal their lack 0f function. No application can fail due to lack of a sub-system’s presence, but any application may be unable to continue due to lack of a specific resource.
This means applications must be aware of the potential for a sub-system to return a “no can do” response.
The architecture of the BOOL RTE (Run Time Environment, also Run Time Engine depending on context) reflects the fundamental nature of BOOL. In particular, that refers to BOOL’s message-passing nature and the use of a parameter stack for passing data. (BOOL call frames use a mechanism not susceptible to stack frame hacks.)
Separate entities in the BOOL environment communicate via message-passing, just as BOOL program objects do (and to a large extent, just as BOOL operates internally). As such, messaging is a native feature of the RTE and is supported in two basic forms.
Essentially, the BOOL RTE is like an operating system. It provides a set of standard systems available to running BOOL programs. The intent is that, as with Java and other platform-agnostic languages, BOOL programs are highly transportable to any platform with a BOOL RTE.