compiz - Dec 2007 - object framework design, part I: OBJECT MODEL

OBJECT MODEL

A hierarchical object model is used. Every object has a name and a
parent reference, which together provide an object path from each
ancestors to the object itself.

It's a single inheritance object system. However, each object can
implement any number of interfaces. All methods and members belong to
some interface. Interfaces that are not part of the object type can be
added and removed dynamically during an object instance's lifetime. LIFO
(Last In First Out) order applies, though.

The system contains built-in support for introspection, hence also safe
invocation of object methods (member functions). 

Object types are not much more than names without an object tree. An
object tree and a parent node is required to instantiate and insert an
object of any other type than the root type. Only one object of the root
type can exist in an object tree. This means that an object type can
optionally be present in only a part of the complete object tree.

To ensure that different modules, unaware of each other, can access,
extend and manipulate an object tree in an robust, easily predictable
and safe manner, object tree processing is done in a very well defined
way. 

These three rules apply for all modules:

1. Member functions should never try to access objects outside its own
sub-tree.
2. Member functions should never invoke member functions in any of its
ancestors.
3. Member functions should never try to access members or children
provided by interfaces that are part of derived types or loaded after
the member functions own interface.

A module that doesn't comply with these rules is considered broken.
However, the object system has been carefully designed so that writing
code that break any of these rules is hard, if not impossible in most
cases, so developers rarely need to worry about it.
>From this description, it might sound similar to some other existing
object systems that could be reused instead of creating this new system.
However, there's a lot of important details that make the extremely
extensible system that we need in compiz efficient, robust and easy to
maintain. This system also takes into account that most compiz modules
will be of a hierarchical nature and very performance sensitive as most
non-performance sensitive code will preferably be moved to a separate
process. More about these details in following posts.

------------

-David