Skip to main content.

Tuesday, September 23, 2008

And with them, full blown tabular programming.

I just need to add some API level method to the Table class; everything at VM level is ready.

With the last round, methods called from dynamic bindings in arrays can access the calling array through the "self" keyword. This lets to build dynamic objects (and classes) not unlike LUA programmers are accustomed to do, but in Falcon there is a significant shift. If an array is part of a table, that is, if it's a row, then properties are taken from the table, and they resolve into an item of the array. So, while bindings stay outside (or besides) the array, table properties lie inside the array itself. Still, a method can access the owning array, and indirectly the owning table, via the "self" item.

There are two goods in that. First, it is possible to change the table definition and so changing all the definitions of its rows with it. Second, all the instances of a certain "class" are safely packed in a place: the Table.

The fun thing of this all is that the overhead of all this with respect to seeing the table just as a set of rows, or the row just as a class instance is nearly 0. There is no relevant performance nor memory impact in just using a table as a matrix of pure data, or to use an array as a funny/dynamic object. This allows to pick the best combination of pure OOP, dynamic binding, table-based classing and table data definition, without too much concern about what would be the most time-memory effective way to achieve a thing. That is, the programmer can chose the representation modality that most fits its needs at hand (and even change it at a later development stage) without being forced to chose one or the other depending on physical constraints. Exactly what I was aiming for.

Actually, I lengthened the declaration of arrays of about 12 bytes (on 32bit machines), but considering that even a single object in the array would be 16 bytes plus array memory block allocation accounting area, this is really a nearly 0 cost; and this is practically the only incremental cost in this deal...

I will write a "philosophical" note about the different usage of bindings, tables and classes to model the reality on the survival guide, hopefully before the next release. A non-technical book on Falcon application design has now become a priority (like lots of other things, I am afraid...)

Comments

No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it