In Disarray

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.

Maybe.

My current thinking (always subject to change) is that BOOL shall have an Array type (specifically: *array). The logic is that BOOL data types (Models aka “classes”) have the potential to be so diverse that building array capability into all of them seems wasteful, redundant and possibly difficult.

Building a specialized array type seems more appropriate.

I’m thinking the syntax looks like this:

*array [10] *int  my_numbers

That creates an array, named my_numbers, that consists of 10 *int objects.

I’m not entirely happy with the reference syntax, but haven’t been able to come up with anything different.  To reference the third member of the array just created above, the syntax is:

[3] my_numbers

Which is actually syntactical sugar for:

index: my_numbers 3

That sends the index: Message to the my_numbers object along with the argument ‘3’.

The array reference syntax is identical to the object member reference syntax.  Given the Model:

**2dPoint
.   *int  x
.   *int  y

You could set the x and y members thus:

*2dPoint  my_point
set: [x]my_point 10
set: [y]my_point 10

Which sets the point to (10,10).

And, as before, this syntax is syntactical sugar.

Advertisements

One response

  1. “…building array capability into all of them seems wasteful, redundant and possibly difficult.”

    In fact, the obvious tactic for a design where all Models can create array instances is to have each Model leverage common array-handling code. That might be a set of functions or an instance of some meta-type, but effectively the common code does form a distinct class.

    (From an AOP perspective, it’s an aspect — a “horizontal” active property shared across otherwise unrelated classes.)

    So an *array Model just reifies that and makes it a top-level über-class that uses another class as a “client” type. This is a different relationship than a delegation, where a Model simply has instances of other Models as instance members (i.e. essentially all user-defined Models).

    A *linked-list or *tree Model might also work like an *array in being a structured aggregate (non-variant) data type, so there needs to be a syntax that supports it. (Because these Models should be definable at the source code level if at all possible. If not, they end up having to be native types.)

%d bloggers like this: