Skip to main content.

Archives

This is the archive for March 2010

Thursday, March 25, 2010

One element of the new object model in the next falcon must surely be the "interface object".

Interface objects are pure abstract class which the final object can expose to Falcon engine. For example, implementing the "dictionary" interface means to expose a Dictionary* object (which is actualy a virtual table pointer) that must be returned implementing something like getDictionary() class. For example:


class MyDict: public CoreObject
{
MyDict():
m_idict( this )
{}

...
virtual DictionaryInterface* getDictionaryInterface() { return &m_idict; }
...

private:

class DictForMyDict: public DictionaryInterface
{
... reimplement the abstract methods from DictionaryInterface
}
m_idict;
};


And of course, the default for get*Interface() function would be that of returning 0, to let the users know that the required interface is not available.

Problems of this model are mainly two. First, adding an interface type requires to break binary compatibility and also a full recompilation of all the modules. Second, but that's a minor issue, the interface require initialization with "this" during constructor, and that raises a warning on many compilers; also, it suggests storing the "this" pointer in the base class, which makes the Interface base class not fully abstract.

Finally, it would be highly desirable to provide the ability to "expose an interface" even to user-provided classes (i.e. its own application classes) without the need to build a wrapper coreobject.

I am figuring out how to solve this problems.

Thursday, March 11, 2010

I have finally been able to release a quite stable bugfix of Falcon version 0.9.6.4. So I took a breath and had a look around and from high above, so that I can plan a good roadmap for the next version.

Also, I notice that my blog is pretty sparse on Falcon. Despite it absorbing a vast part of my everyday life, I rearely write about it in the blog; I prefer to "do" rather than to "argue". Yet, today a couple of questions about some arguments in the Newsgroup have fired the considerations I usually keep for myself, or for the few people on our chat channel.

I immediately thougth that writing some ideas, doubt, solutions down here is much better than keeping them for myself, so I'll be using my blog to keep track of what is going around my mind about Falcon much more regularly from now on.

The achievements I want to obtain in the next version are the final stabilization of the Embedding/module writing API, together with the new Item model and the new compiler/moduler/linker triplet. If it seems ambitious, it must be considered that those elements are tightly interrelated, and cannot exist without each other. So the fix order must be:

Deep item/garbage model -> Item framework -> Syntactic tree -> Module/VM/Runtime -> Compiler

Also, some iterative process will be required. A redesign of the inheritance resolution pattern will require to do a first VM/Link passage, and then continue again into the Deep/item garbage model.

More tomorrow.