10.25.5.2 Limitations

This section summarizes the current limitations of SICStus Objects.

Debugging

When you debug SICStus Objects programs that were compiled using the obj_decl module, you are tracing the translated version of your code. This includes all method clauses and (some) message sending commands.

The source-linked debugger cannot connect compiled SICStus Objects code with the source code.

Garbage Collection

There is no garbage collection of objects. It is the responsibility of the programmer to keep track of unused objects. In particular, avoid doing the following:

| ?- create(Class, Object).

Unless the create message for Class made some provision for finding the new object again, it is now lost. It cannot be used, and it cannot be destroyed.

Multiple Inheritance

The provisions for multiple inheritance in this version of SICStus Objects are limited. In particular, there is no control over the inheritance of slots, which makes repeated inheritance impossible. However, it does support the mixin style of multiple inheritance.

Persistence

While objects are more persistent than Prolog variables, there is no automatic way to save objects from one execution of your program to the next. Hence they are less persistent than the clauses in the Prolog database.

If you need to save a set of objects from one Prolog session to another, then copy the objects to the Prolog database as terms, and save them to a QOF file. Then, after you reload the QOF file, rebuild the objects. Keep in mind that addresses are not valid from one session to another.

In short, there is no way to avoid initializing objects at run time.