| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (3 out of 6)

Using Module Prefixes

A typical G2 application consists of numerous modules, which you merge together to create a complete application. During development, especially if you are working in a team, you might mistakenly define two items of the same name in two different modules, each with a different definition. This might occur when defining classes, methods, procedures, or functions.

When you attempt to merge two such modules into a single application, G2 presents a conflict workspace indicating that two different definitions exist. By default, G2 renames the definition in the module that you merged by appending -from-module-name to the name, for example, robot-from-defs.

To avoid this type of cross-module conflicts, we recommend that you use module prefixes and that you following these naming conventions:

Assign each module a unique, short prefix, usually three to six letters.
Name all items and attributes in the module with the module prefix.

Caution: G2 makes no assurances that module prefixes are unique. Thus, you might have to establish a prefix reservation system to prevent naming conflicts.

Benefits of Using Module Prefixes

Using the module prefix on all items and attributes has numerous benefits:

Using module prefixes ensures that you will always have unique names, which means search and replace operations in Inspect will never find items or attributes with similar names or names that are substrings of other names.
Using module prefixes reduces the potential for confusion from similarly named attributes when documenting and maintaining your KB, for example, if different modules define generically named attributes such as status, ID or label.
Reduces the potential for confusion from inheritance conflicts. For example, if the user creates a subclass C that inherits from two classes, A and B, each of which defines an attribute named status, G2 creates class-qualified attribute names for each attribute, A::status and B::status. If a method for class C references the status attribute without using a class-qualified name, the reference will be ambiguous and run-time errors will result.

Costs of Using Module Prefixes

Using the module prefix on all items and attributes carries these costs, which you should also be aware of:

You must use the prefix consistency for all attributes and items in the module, which can be tedious.
If used inconsistently, can result in confusion or incorrect behavior.
If you need to change the prefix name for any reason, you must replace all references to the module prefix in every item in the module, using Inspect, which can be time-consuming and is error prone.
Attribute and class names are no longer as immediately legible.
You typically need to create some type of end user interface for entering values, depending on the type of end user.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (3 out of 6)

Copyright © 1997 Gensym Corporation, Inc.