Skip to main content.

Thursday, April 08, 2010

Talking with the people in #falcon IRC channel (at, we worked out the concept a bit, and we found out that the best place where to store the interface objects is the Falcon "CoreClass" instance.

The CoreClass has the meaning to describe what Falcon can do with the data you pass. Rather than storing the knowledge of how to handle the object in the CoreObject hierarcy, we can think of the object as a totally opaque entity, and store all the knowledge about it in the CoreClass.

This allows embedders and modules to provide totally opaque data (their data) and separate it from the code that Falcon should use to handle it.

The way to associate CoreClasses with the opaque data they should handle is still under investigation. One option is that of just storing the class and its opaque data in the item, but then we must make sure that a method creation (obj.mth) has a way to refer the class. Shouldn't be too hard in the new model we're developing, as the methods may now have a back-reference to the classes from which they come from.

Another option may that of having a pool of pre-allocated small buffers where the opaque-data / handler-class pair can be stored, and then store that pointer in the items. This has the advantage that we're sure that the opaque data can never be disconnected from the class, but it requires extra allocation, memory management and dereferences.

The current coupling of methods and objects on which they operate solves a problem similar to this, and has been proven one of our most solid assets since first alpha release; so, keeping the pair class/opaque-object or method(class)/opaque-object directly in the item structure seems a very smooth and viable solution.


No comments yet

Add Comment

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