@fredrik, I appreciate your efforts to explain this, but I think there must be some things that I’m not yet seeing. Suppose, for example, I wanted to set up a class of active NPCs that keep track of the last 50 things that they’ve seen – perhaps to allow them to make idle comments about things in the environment. I would want to do something like:
Class ObservantNPC
with objects_seen table 50, ! imaginary syntax
choose_observed_object [ i chosen_obj ;
i = random(self.objects_seen-->0);
chosen_obj = self.objects_seen-->i;
if (chosen_obj == nothing) ... ! handle looking for another choice if entry is empty
return chosen_obj;
],
make_object_comment [ obj ;
obj = self.choose_observed_object();
switch(obj) {
sword: "My grandfather had one like that over the fireplace in his small white house.";
... ! assorted default statements here
}
],
daemon [;
... ! examine the NPC object's location and update self.objects_seen accordingly
];
with the idea that I can later check (npc_var ofClass ObservantNPC) and conditionally send npc_var.make_object_comment();. (Please forgive any faults in the imaginary logic above.)
This is a situation where (from what I understand now) it would require declaring an external array for every ObservantNPC instance and then manually assigning the appropriate array to each instance in Initialise() or the like. I’m in no way an advanced programmer, so if there’s some elegant shortcut to avoid this requirement, please share it – I would appreciate it.
As you point out, the existing property arrays (what I’m calling “embedded arrays” above) can’t be wholesale replaced, and shouldn’t be. But the idea would be that the objects_seen property is just a single-entry embedded array (what I’m calling an “attached array” above), more like favorite_color or current_age than name, and just like it would exist if the “naked” property is declared without a value (as must be done now if one wants to attach an external array). It would hold the pointer to an compiler-generated external array structurally identical to one declared via:
Array insert_generated_name_here table 50;
That kind of automatic array would only be generated if keywords table, string or buffer followed the property name. A simple list of values would follow current rules, and would be compiled to a property array in the object’s property table.
I do agree that there is room for confusion about the difference between a “normal array” and a “property array”… but I suggest that there would be no net new confusion added by this change, as the distinction already exists and is covered in DM4. I wouldn’t expect a hypothetical beginning programmer to be confused when the property that they explicitly ask to be set up as an attached array does, in fact, function as one!
As one data point: My own personal confusion in precisely the learning scenario that you outline was that the compiler didn’t seem to allow declaration of an attached array under any circumstances. (… which was why I was later pleased to discover a possible workaround, then even later started to wonder about why it had to be worked around in the first place.)