UPF Concepts

Like UPF takes approach similar to Java. There are interfaces that define the API and are abstract in the sense that you can't have instance of an interface. Objects/instances can only be created for classes. A class implements one of more interfaces -- that is, provides code for methods with same names and prototypes as these defined in the interface(s) it implements.

An object can be queried for particular interface (see upf::IObject::queryInterface). The object returns interface identification if it implements it or informs the caller that given interface is not supported by this class.

For example, you may have interface IFoo and IBar and classes A, B and C, where A implements interface IFoo, B implements IBar and C implements both interfaces. You can access both A and C via IFoo API (interface).

Interfaces in UPF are versioned. Every interface has two version numbers associated with it: major and minor. Any two interfaces with different major version numbers are incompatible (i.e. a module that knows one version of the interface cannot interoperate with another one which implements different version).

If major numbers are same and two interfaces only differ in minor version, then the situation is different: the class that implements interface with higher minor version is assumed to implement all lower minor versions of the interface. If, for example, A implements version 1.2 of an interface and B implements version 1.1, then B can safely access A (because it is compatible with 1.2, 1.1 and 1.0), but A cannot use with B (because A only knows version 1.2 of the interface whereas B can only provide versions 1.1 or 1.0).

Version is specified using #pragma version (interface) (major).(minor) declaration in IDL file. If the pragma is omitted, version 1.0 is assumed. Here is an example:

interface Foo : upf::IObject
{
    ...
};

#pragma version Foo 2.3

Attention:

You must increment major version number every time you change your interface in a binary incompatible way. These modifications are binary compatible:

• adding method or attribute to the end of interface definition
• adding typedefs, enums and structs

These are not:

• adding methods/attributes elsewhere
• changing methods prototypes (aka signatures)
• changing types of attributes

Reference Counting

Objects in UPF are reference-counted. Whenever your code uses some object (via its interface), it must aquire a reference and release it when it no longer needs the object. An object is destroyed only when its reference count reaches zero.

Reference counting is mostly hidden from the programmer by language-specific constructs. In C++, for example, the programmer should use upf::Ptr template class.

It is important to be aware of UPF's use of reference counting because sometimes circular references may occur and if you don't handle such situations in your code, the app would leak memory.

Properties

A class may have arbitrary number of properties associated with it. Property is a key-value pair where both key and value are arbitrary strings. Properties don't have any special meaning, their interpretation is fully up to the application.

Some properties have meanings associated with them by convention, though:

• Author
• Copyright
• PartOf - what library/component is this class part of (e.g. "UPF Core")?
• ImplLanguage - programming language used to implement the class (e.g. "C++")
• Description - human-readable description of class' purpose

See also:

upf::IClassInfo

---