Logtalk, as an object-oriented extension to Prolog, shares with it the same preferred areas of application but also extends them with those areas where object-oriented features provide an advantage compared to plain Prolog. Among these areas we have:
For a successful programming in Logtalk, you need a good working knowledge of Prolog and an understanding of the principles of object-oriented programming. All guidelines for writing good Prolog code apply as well to Logtalk programming. To those guidelines, you should add the basics of good object-oriented design.
One of the advantages of a system like Logtalk is that it enable us to use the currently available object-oriented methodologies, tools, and metrics [Champaux 92] in Prolog programming. That said, writing programs in Logtalk is similar to writing programs in Prolog: we define new predicates describing what is true about our domain objects, about our problem solution. We encapsulate our predicate directives and definitions inside new objects, categories and protocols that we create by hand with a text editor or by using the Logtalk built-in predicates. Some of the information collected during the analysis and design phases can be integrated in the objects, categories and protocols that we define by using the available entity and predicate documenting directives.
A Logtalk source file must contain only one entity, either an object, a category, or a protocol. It is recommended that each source file be named after the entity identifier. For parametric objects, the identifier arity can be appended to the identifier functor. By default, all Logtalk source files use the extension .lgt but this is optional and can be set in the configuration files. Compiled source files (by the Logtalk preprocessor) have, by default, a .pl extension. Again, this can be set to match the needs of a particular Prolog compiler in the corresponding configuration file. For example, we may define an object named vehicle and save it in a vehicle.lgt source file that will be compiled to a vehicle.pl Prolog file. If we have a sort(_) parametric object we can save it on a sort1.lgt source file that will be compiled to a sort1.pl Prolog file. This name scheme helps avoid file name conflicts (remember that all Logtalk entities share the same name space).
Any Logtalk source file can contain arbitrary directives and clauses before the opening entity directive. These directives and clauses will not be compiled by the Logtalk preprocessor and will be copied unchanged to the beginning of the corresponding Prolog output file. This feature is included to help the integration of Logtalk with other Prolog extensions like, for example, constraint programming extensions.
Logtalk is compatible with almost all modern Prolog compilers. However, this does not mean that our Logtalk programs will have the same level of portability. If possible, we should only use in our programs Logtalk built-in predicates and ISO Prolog defined built-in predicates. If we need to use built-in predicates that may not be available in other Prolog compilers, we should try to encapsulate the non-portable code in a minimum of objects and provide a portable interface for that code. An example will be code that access operating-system specific features. The Logtalk compiler can warn us of the use of non-ISO defined built-in predicates by using the portability/1 compiler option.
Try to write objects and protocol documentation before writing any other code; if you are having trouble documenting a predicate perhaps we need to go back to the design stage.
Try to avoid lengthy hierarchies. Besides performance penalties, composition is often a better choice over inheritance for defining new objects. In addition, prototype-based hierarchies are conceptually simpler and more efficient than class-based hierarchies.
Dynamic predicates or dynamic entities are sometimes needed, but we should always try to minimize the use of non-logical features like destructive assignment (asserts and retracts).
Since each Logtalk entity is independently compiled, if an object inherits a dynamic or a metapredicate predicate, then we must repeat the respective directives in order to ensure a correct compilation.
In general, Logtalk does not verify if a user predicate call/return arguments comply with the declared modes. On the other hand, Logtalk built-in predicates, built-in methods and message sending control structures are carefully checked for calling mode errors.
Logtalk error handling strongly depends on the ISO compliance of the chosen Prolog compiler. For instance, the error terms that are generated by some Logtalk built-in predicates assume that the Prolog built-ins behave as defined in the ISO standard regarding error conditions. In particular, if your Prolog compiler does not support a read_term/3 built-in predicate compliant with the ISO Prolog Standard definition, then the current version of the Logtalk preprocessor will not be able to detect misspell variables in your source code.