But hopefully once and for all. What started in Disarray, and then seemed briefly Final, yet was still Revisited, has, just perhaps, at last settled into a design that doesn’t nag me. (Or, at least, doesn’t nag me so much I find myself constantly chewing on the bone.)
It feels that I have finally solved how I want BOOL to do arrays!
Picking up the topic of Model implementation two years later, some further thoughts about the new method as well as about the set and get methods.
The summary here is that all three are virtual methods built into the implementation. They have to be to handle the under-the-hood aspects of Instances. They can be “extended” by user code, but not over-ridden.
One of the last hurdles involves the implementation of the new behavior. Models manage Instance value objects and provide new data objects (used by Instance objects to populate Call Frame slots). Model objects must provide an API to support creating and destroying Instance objects as well as manipulating their value objects.
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.