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.
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.
I’ve changed my mind about the Gated List syntax. (These mind-changes are a key reason BOOL design is endless!) The idea of binding a label to the first statement in a List to indicate a Gated List just didn’t make good sense to me.
The problem is two-fold: Firstly, a key reason for Gated Lists in the first place is their use as named Action clauses. When the label is buried in the List (because it now belongs to the first List member), there’s no sensible way to migrate the label to the List. Secondly, a label on the gate expression really makes no sense and has no value.
So I’ve come up with something new!
I’m once again having a go at creating a BOOL Reference Implementation. I’ve tried this in code nearly half a dozen times before, and I’ve doodled countless lines of pseudo-code over the years, but I’ve always gotten bogged down in details and unknowns before.
I think I just solved a long-open issue in BOOL regarding conditional Lists. It’s something that’s been nagging me a long time. For one thing, it’s one place that’s line-sensitive, and BOOL tries to avoid that. (Actually BOOL is very line-sensitive, but not that way.)
The other thing is that it conflated two things into one, and that’s also to be avoided. Clarity is everything, and not overloading concepts is an important part of clarity. (Orthogonality is another clarity goal that BOOL considers important.)
The background for this goes back to a BOOL primary design goal and technique.
One of the things that’s kept me from completing BOOL is that I haven’t been able to make up my mind regarding arrays.
There are two basic directions: All data types can have the native ability to create single or array instances, or the Array type is a special data type that can make an array instance of any data type.
There is also the issue of what should be the array syntax. How are arrays declared, and how are array members referenced?
I think, after all this time, I have finally made up my mind.