Method for mapping types stored in a model in an object-oriented repository to language constructs for A C binding for the repository

Abstract

The method of the present invention is useful in a computer system having a user interface, a CPU, a memory, at least one disk drive, and an object-oriented repository, a program operating in the computer system for accessing the object-oriented repository. The program executes a method for mapping types in a model stored in the repository to language constructs for a C binding to the repository. The method first processes each type in the model, then the program processes each data type in the model. Function declarations and C to C++ wrapper functions are generated for each type and data type.

Claims

What is claimed is:

1. In a computer system having a user interface, a CPU, a memory, at least one disk drive, and an object-oriented repository, a program operating in said computer system for accessing said object-oriented repository, said program executing a method for mapping types in a model stored in said repository to language constructs for a C binding to said repository and writing said language constructs to a file on said at least one disk drive comprising the steps of:

a. for each type in said model, determining if a current one of said types is valid for C binding, and if so;

b. generating object initializer function declarations for said current type;

c. determining if there are more properties for said current type, and if so;

d. for each property for said current type, determining if a current one of said properties is valid for C binding, and if so;

e. generating accessor function declarations for said current property;

f. determining if said current property is not read-only, and if so;

g. generating mutator function declarations for said current property;

h. if there are no more properties for said current type, determining if there are more operations for said current type, and if so;

i. for each operation for said current type, determining if a current one of said operations is valid for C binding, and if so;

j. resolving operation name for said current operation;

k. generating declaration for said current operation;

l. if there are no more operations for said current type, generating special function declarations; and,

m. generating C to C++ wrapper functions for said current type;

n. determining if there are more of said types in said model, and if so, repeating steps a through n hereof;

o. if there are no more types, then;

p. for each data type in said model, determining if a current one of said data types is valid for C binding, and if so;

q. generating function declarations for said current data type;

r. generating C to C++ wrapper functions for said current data type;

s. determining if there are more data types in said model, and if so, repeating steps p through s hereof; and,

t. if there are no more data types in said model, stopping said program.

2. A method as in claim 1 wherein said step of generating C to C++ wrapper function for said current type further comprises:

u. generating object initializer functions for said current type;

v. determining if there are more properties for said current type, and if so;

w. for each property for said current type, determining if a current one of said properties is valid for C binding, and if so;

x. generating C to C++ wrapper code for accessor functions for said current property,

y. determining if said current property is not read-only, and if so;

z. generating C to C++ wrapper code for mutator functions for said current property;

aa. if there are no more properties for said type, determining if there are more operations for said type, and if so;

ab. for each operation for said type, determining if a current one of said operations is valid for C binding, and if so;

ac. resolving operation name for said current operation;

ad. generating a C to C++ wrapper function for said current operation; and,

ae. if there are no more operations for said type, generating a wrapper function for any special operations; and,

af. returning to step n of claim 1 hereof.

3. A method as in claim 2 wherein said step of generating C to C++ wrapper code for accessor functions further comprises:

ag. generating function heading with correct parameters;

ah. generating code to check myself parameter;

ai. generating code for return if an error was found;

aj. generating code to call C++ accessor;

ak. generating code to return a value for said accessor; and,

al. returning to said program at step y of claim 2.

4. A method as in claim 2 wherein said step of generating C to C++ wrapper code for mutator functions further comprises:

ag. generating function heading with correct parameters;

ah. generating code to check myself parameter;

ai. determining if said current property type is an object, and if so;

aj. generating code to check object parameter;

ak. generating code for return if an error was found;

al. generating code to call C++ mutator; and,

am. returning to step w of claim 2 hereof.

5. A method as in claim 2 wherein said step of generating C to C++ wrapper function for an operation further comprises:

ag. generating function heading with a return type and a parameter list for said operation;

ah. determining if said operation is a class operation, and if so;

ai. generating a check for UREP object parameter;

aj. if said operation is not a class operation, generating a check for myself object parameter;

ak. determining if there are more parameters, and if so;

al. for each parameter, declaring a local variable for correct type for a current one of said parameters;

am. determining if said current parameter is a data type, and if so,

an. generating an assignment to said local variable;

ao. if said current parameter is not a data type, determining if said current parameter is optional, and if so;

ap. generating a check for a null object for said current parameter;

aq. generating a call to check object function for said current parameter;

ar. generating code to store value in said local variable;

as. if there are no more parameters for said operation, determining if said operation has a return value, and if so;

at. generating code to return a null object if an error was found;

au. if said operation does not have a return value, generating code to return if an error occurs;

av. determining if said operation returns a value or a has a parameter that returns a value, and if so;

aw. generating a local variable to hold said return value;

ax. generating a call to said operation in C++ binding, and capturing said return value in said local variable;

ay. determining if said current operation has output or input/output parameters, and if so;

az. generating code to transfer values from C++ operation call to each of said parameters;

ba. generating code to store said return value;

bb. generating a return;

bc. if said current operation does not return an object, generating a call to C++ operation in a return statement;

bd. if said current operation does not return a parameter with an object, generating a call to C++ operation in a return statement; and,

be. returning to said program at step ab of claim 2 hereof.

6. A method as in claim 1 wherein said step of generating function declarations for said current data type further comprises:

u. determining if said current data type needs values, and if so;

v. generating values for said current data type;

w. determining if said current data type is not symbolic, and if not:

i) generating object initializer declarations;

ii) generating conversion function declarations;

x. determining if said current data type is symbolic, and if so;

y. generating format and conversion function declarations;

z. if said current data type is not symbolic, generating class id and model id function declarations; and,

aa. returning to said program at step r of claim 1 hereof.

7. A method as in claim 1 wherein said step of generating C to C++ wrapper functions for said current data type further comprises:

u. determining if said current data type is not symbolic, and if not:

i) generating object initializer functions;

ii) generating conversion functions;

v. if said current data type is not not symbolic, determining if said current data type is symbolic, and if so;

w. generating format and conversion functions;

x. if said current data type is not symbolic, generating class id and model id functions; and,

y. returning to said program at step s of claim 1 hereof.

8. In a computer system having a user interface, a CPU, a memory, at least one disk drive, and an object-oriented repository, a program operating in said computer system for accessing said object-oriented repository, said program executing a method for mapping types in a model stored in said repository to language constructs for a C binding to said repository and writing said language constructs to a file on said at least one disk drive comprising the steps of:

a. for each type in said model, determining if a current one of said types is valid for C binding, and if so;

b. generating object initializer function declarations for said current type;

c. determining if there are more properties for said current type, and if so;

d. for each property for said current type, determining if a current one of said properties is valid for C binding, and if so;

e. generating accessor function declarations for said current property;

g. determining if said current property is not read-only, and if so;

h. generating mutator function declarations for said current property;

i. if there are no more properties for said current type, determining if there are more operations for said current type, and if so;

j. for each operation for said current type, determining if a current one of said operations is valid for C binding, and if so;

k. resolving operation name for said current operation;

l. generating declaration for said current operation;

m. if there are no more operations for said current type, generating special function declarations;

n. generating C to C++ wrapper functions for said current type;

o. determining if there are more of said types in said model, and if so, repeating steps a through n hereof;

p. if there are no more types, then;

q. for each data type in said model, determining if a current one of said data types is valid for C binding, and if so;

r. generating function declarations for said current data type;

s. generating C to C++ wrapper functions for said current data type; and,

t. determining if there are more data types in said model, and if so, repeating steps q through s hereof;

u. if there are no more data types in said model, stopping said program.

9. A method as in claim 8 wherein said step of generating C to C++ wrapper functions for said current type further comprises:

v. generating object initializer functions for said current type;

w. determining if there are more properties for said current type, and if so;

x. for each property for said current type, determining if a current one of said properties is valid for C binding, and if so;

y. generating C to C++ wrapper code for accessor functions for said current property,

z. determining if said current property is not read-only, and if so;

aa. generating C to C++ wrapper code for mutator functions for said current property;

ab. if there are no more properties for said type, determining if there are more operations for said type, and if so;

ac. for each operation for said type, determining if a current one of said operations is valid for C binding, and if so;

ad. resolving operation name for said current operation;

ae. generating a C to C++ wrapper function for said current operation; and,

af. if there are no more operations for said type, generating a wrapper function for any special operations; and,

ag. returning to step o of claim 8 hereof.

10. A method as in claim 9 wherein said step of generating C to C++ wrapper code for accessor functions further comprises:

ah. generating function heading with correct parameters;

ai. generating code to check myself parameter;

aj. generating code for return if an error was found;

ak. generating code to call C++ accessor;

al. generating code to return a value for said accessor; and,

am. returning to said program at step z of claim 9.

11. A method as in claim 9 wherein said step of generating C to C++ wrapper code for mutator functions further comprises:

ah. generating function heading with correct parameters;

ai. generating code to check myself parameter;

ad. determining if said current property type is an object, and if so;

ak. generating code to check object parameter;

al. generating code for return if an error was found;

am. generating code to call C++ mutator; and,

an. returning to step x of claim 9 hereof.

12. A method as in claim 9 wherein said step of generating C to C++ wrapper function for an operation further comprises:

ah. generating function heading with a return type and a parameter list for said operation;

ai. determining if said operation is a class operation, and if so;

aj. generating a check for UREP object parameter;

ak. if said operation is not a class operation, generating a check for myself object parameter;

al. determining if there are more parameters, and if so;

am. for each parameter, declaring a local variable for correct type for a current one of said parameters;

an. determining if said current parameter is a data type, and if so,

ao. generating an assignment to said local variable;

ap. if said current parameter is not a data type, determining if said current parameter is optional, and if so;

aq. generating a check for a null object for said current parameter;

ar. generating a call to check object function for said current parameter;

as. generating code to store value in said local variable;

m. if there are no more parameters for said operation, determining if said operation has a return value, and if so;

at. generating code to return a null object if an error was found;

au. if said operation does not have a return value, generating code to return if an error occurs;

av. determining if said operation returns a value or a has a parameter that returns a value, and if so;

aw. generating a local variable to hold said return value;

ax. generating a call to said operation in C++ binding, and capturing said return value in said local variable;

ay. determining if said current operation has output or input/output parameters, and if so;

az. generating code to transfer values from C++ operation call to each of said parameter;

ba. generating code to store said return value;

bb. generating a return;

bc. if said current operation does not return an object, generating a call to C++ operation in a return statement;

bd. if said current operation does not return a parameter with an object, generating a call to C++ operation in a return statement; and,

be. returning to said program at step ac of claim 9 hereof.

Description

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The present invention relates to the field of object-oriented repositories in general, and in particular to a method for interfacing between an object-oriented repository employing the C++ programming language and programs written in another programming language.

BACKGROUND OF THE INVENTION

A repository enables the storage and reuse of information about an enterprise. Such information could be definitional (such as programs, files, and the relationships therebetween), management information (e.g., who can see certain types of information, etc.) and operational information (such as schedules, processes, etc.) In an object-oriented repository, this information is stored as objects that have data (e.g., name, salary, etc.) and behavior (e.g., change salary, etc.). The C++ language, with its object-oriented syntax is well suited as an interface to an object-oriented repository. For more information on such an interface reference is made to a co-pending patent application by Peter Johnson for A METHOD FOR PROVIDING OBJECT DATABASE INDEPENDENCE IN A PROGRAM WRITTEN USING THE C++ PROGRAMMING LANGUAGE, Ser. No. 08/505,140, filed Jul. 21, 1995; which application is assigned to the same assignee hereof.

However, having just a C++ interface limits the types of programs (or tools) that can have access to the object-oriented repository to only those programs written in the C++ language. It would be beneficial to have an interface that would allow access to the object-oriented repository by programs written in the C language. In addition, programs written in languages that can access dynamic link libraries (DLL's on Windows NT), or shared objects (UNIX), will benefit from access to an object-oriented repository by use of the method of the present invention. Examples of such language include Visual Basic, Smalltalk and other similar languages.

A problem with C interfaces to object-oriented databases is that the functions provided are not tailored to the types in the database. For example, in some implementations in order to create an object in the database, the C program must first call the database to retrieve a representation of the desired type, then call a generic create function to create the object. The method of the present invention solves this problem by generating functions tailored to each of the types in a model in the repository. One function call is required to create an object of a specific type. Similarly, one function call is used to access the properties and operations of types in the repository

Another problem with C interfaces to object-oriented databases is that the functionality available through the C interface is limited compared to the C++ interface to the same object-oriented database. This invention provides almost 100% of the functionality available through the public C++ interface to the repository.

Still another problem is that the C and C++ interfaces can be constructed quite differently with much of the object-orientedness of the types in the database being lost when translated to C. The method of the present invention provides a C interface that maps the C++ types, operations and properties in a straightforward manner to the C language. This reduces the amount of documentation necessary for both interfaces, as well as programmer learning time going from one interface to the other.

The present invention provides a C interface to an object oriented repository by making the public properties and operations of the types in the repository available to programs written in the C language, or accessed via DLLs, or shared objects from other languages. A program written in the C language can open an object-oriented repository, log in to the repository, begin a repository session, and create, retrieve, and modify instances of the types in the repository. The purpose of the method of the present invention is to convert the types, properties, and operations defined for a model into constructs understood by a C compiler, for example. The Application Program Interface (API) for the C binding includes a set of header files that contain the C type and function declarations necessary to access instances of the types in the object-oriented repository. A set of C++ files provides a wrapping between the C functions that can be called by a program written in the C language and the C++ interface provided by the object-oriented repository.

BRIEF SUMMARY OF THE INVENTION:

It is therefore an object of the present invention to provide a well-defined interface to an object-oriented repository for a program written in the C language.

Still another object of the present invention is to provide mapping of the types and features of an object-oriented repository to the C programming language.

Yet another object of the present invention is to allow languages that call a dynamic link library (DLL) to access the object-oriented repository through the C binding.

The method of the present invention is useful in a computer system having a user interface, a CPU, a memory, at least one disk drive, and an object-oriented repository, a program operating in the computer system for accessing the object-oriented repository. The program executes a method for mapping types in a model stored in the repository to language constructs for a C binding to the repository comprising the steps of: for each type in the model, determining if a current one of the types is valid for C binding, and if so; generating function declarations for the current type; generating C to C++ wrapper functions for the current type; determining if there are more of the types in the model, and if so, repeating the steps above. If there are no more types, then the program continues processing for each data type in the model, determining if a current one of the data types is valid for C binding, and if so; generating function declarations for the current data type; generating C to C++ wrapper functions for the current data type; and, determining if there are more data types in the model, and if so, repeating the last three steps hereof. If there are no more data types in the model, stopping the program.

BRIEF DESCRIPTION OF THE DRAWINGS:

FIG. 1 a generalized block diagram of a system that may use the method of the present invention.

FIG. 2 is a block diagram illustrating the binding generation and run-time environment.

FIG. 3 illustrates an example of constructing a surrogate object in a C program.

FIG. 4 illustrates an example of calling an operation on objects in a repository from a C program.

FIG. 5 is a flow chart that illustrates the steps for generating C binding.

FIG. 6 is a flow chart that illustrates the steps for generating function declarations for types.

FIG. 7 is a flow chart that illustrates the steps for generating C to C++ wrapper functions.

FIG. 8 is a flow chart that illustrates the steps for generating C to C++ wrapper code for accessor and mutator functions.

FIGS. 9A and 9B combined form a flow chart that illustrates the steps for generating the C to C++ wrapper function for an operation.

FIG. 10 is a flow chart that illustrates the steps for generating C function declarations for data types.

FIG. 11 is a flow chart that illustrates the steps for generating C to C++ wrapper functions for data types.

DETAILED DESCRIPTION

Before proceeding with a detailed description of the method of the present invention a background discussion of object-oriented repositories would be helpful. This discussion will focus on the terminology used herein. Background information that may be helpful in understanding the present invention may be had by reference to U.S. Pat. No. 5,644,764 also assigned to the assignee of this application and entitled A METHOD FOR SUPPORTING OBJECT MODELING IN A REPOSITORY.

The term"binding" as used herein refers to a mapping of the types and features (i.e., attributes, references, and operations) of a model to language constructs, such as C functions for C binding, or C++ classes and operations for C++ binding. An example of binding would be to assign a Word macro to a key combination in Word for Windows. The user binds the macro to a key (e.g., alt-s) so that when one presses alt-s, the macro gets executed. In the context of a repository, such as the Universal Repository (UREP) available from Unisys Corporation of Blue Bell, Pa., calling C functions in the UREP C binding causes the corresponding repository operations to be executed. The term "mapping" as used herein refers to the establishment of a correspondence between two sets that associates each member of the first set (i.e., types) with a single member of the other set (i.e., language constructs for C binding for the repository). Additional background information on object technology and terminology is also given hereinbelow to provide a common ground in which to discuss the invention.

Referring now to the drawings and FIG. 1 in particular, a block diagram is shown of a computer system 8 including an operator console 9 a CPU 10 and a memory 11. The system 8 has access to databases stored in disk drives 12, 13 and 14 by means of a bus 15 coupled through an application programming interface ("API") 16. The API 16 is coupled to the system 8 by means of a C binding layer, which is schematically illustrated in FIG. 1 as layer 17 representing the method of the present invention. That is, the software running in the memory 11 accesses one or more of the databases 12-14 by means of the C binding layer 17.

Object Terminology

A normal object program stores objects in the computer system's memory 11. When the program terminates, the memory used by those objects is freed and reused by other programs, making the objects that the program stored transient. An object database stores objects on a computer disk. Since the information on a computer disk remains in existence, even when the computer is turned off, an object database provides the ability to persistently store objects. An object program that uses an object database thus has the option of storing objects transiently or persistently.

An object is an abstract representation of a real-world concept or thing. For example, an object can be used to represent a customer account in a banking application. An object has features, which can be either an operation or a property. An operation defines an action that an object can perform, or an action that can be performed on the object. For example, "make withdrawal" could be defined as an operation on a customer account object. Properties indicate the state of an object. Every property of an object has a value, and it is the property values that define the state of the object. A property can be either an attribute or a reference. An attribute defines a value that is stored within the object. For example, "current account balance" could be an attribute of the customer account object. The numeric value for the customer's account balance would be stored in the customer account object. A reference is a link or pointer to another object, and implies a relationship to that other object. A reference is typically used when it is desired not to duplicate data. For example, the customer account object could store the customer's name and address as attributes. But, if the customer opened multiple accounts, the customer's name and address would appear in multiple account objects. Therefore, it is desirable to define a separate customer object and place the name and address as attributes of the customer object. The customer account object would then contain a reference to the customer object.

With reference to FIG. 2, a block diagram is shown that illustrates the binding generation and run-time environment. A Universal Repository ("UREP") 18 includes a metadata service 18A, which is a repository service for retrieving information about a model stored in the repository. A binding generator 19 is disposed for converting the types, properties and operations defined for the model into constructs understood by a C compiler 20. A C binding template files 21 provides an interpreted language used by the generator 19 to produce C header files 22, and C to C++ wrapper files 23. The C to C++ wrapper files provide an interface between the C functions and the equivalent C++ operations. The C compiler 20 accepts a tool source file 24 and the C header files 22 to produce a tool program 25.

The C to C++ wrapper files 23 are compiled and linked by a C++ compiler 26 into a C to C++ wrapper library 27. The functions performed by the wrapper library 27 check the validity of C parameters and call equivalent C++ functions in a corresponding model C++ library 28. The function performed by the C to C++ wrapper library 27 takes care of any parameter and return value translation to and from C and C++. At run-time, the tool program 25 makes C calls to the C to C++ wrapper library 27, which in turn calls t he model C++ library 28.

Referring now to FIG. 3, an example of constructing a repository object in a C program is illustrated. The C program is graphically depicted by a block 30, wherein a function call, initdUrepNamedobject, is illustrated as creating an instance of the UrepNamedobject type in memory. When the function is called by the C program, C Binding (block 31) creates a new instance of the UrepNamedobject type on the heap. This new object is added to the next free entry (N) in the object list (block 32) maintained by the C Binding 31. The index of the entry is returned to the calling C program 30. The value of X is the index.

Referring now to FIG. 4, the C program 30 declares a variable, X, of type UrepArray. This variable will hold the return value. Next the C program 30 calls the "UrepNamedObject.sub.-- getByName" function, passing four parameters. The last parameter indicates that no value is passed for an optional parameter. Inside the C Binding (block 31), the parameters that are objects (the first and last in this case) are checked. The first parameter is checked to make sure it is of type UREP. If it is, it is retrieved from the object list (32). The last parameter is null (NULL-OBJECT) and was passed, so a UrepNamespace is constructed to pass as a parameter. Then the C++ operation, UrepPersistentObject::getByName is called, passing in four parameters: The UREP object retrieved from the object list 32, the string variable, name, the enumerated variable, count, and the namespace object that was constructed inside the C Binding 31.

The operation is in the C++ binding (block 33), which calls the repository to retrieve the objects with the desired name in the default namespace. The C++ Binding 33 returns a UrepArray of UrepNamedObjects to the caller, the C Binding 31. The C Binding then creates a copy of the array on the heap and adds it to the next empty entry in the object list. The index of this entry (M), is returned to the C program 30. The C program now has an index which allows it to call functions which accept a UrepArray, such as size and lookup.

Description of one Embodiment: C language binding to an Object-Oriented Repository

C Access to Objects

In the C interface, surrogate objects are used to access instances of UREP types, whether persistent or transient. The term "UREP" or "Urep" refers to a Universal Repository, which is a software product available from Unisys Corporation, assignee of this patent application. Because the C language does not have classes or objects, a C typedef is created for each UREP type. The term "typedef" is a language construct of the C programming language, which is used to give a name to a data type. Variables declared using these typedefs are surrogate objects and represent links to instances of the corresponding UREP type. These surrogate objects can then be initialized and used as parameters to UREP operations. The typedef is used to hide the implementation of the C binding. An example surrogate object declaration is:

UrepVersionedObject myobj;

As used herein, the terms object and instance are used to represent a persistent or transient instance of a UREP type or model type, even though the C language itself does not have similar concepts. An object initializer function must be called to initialize the object before it is used. Once initialized, an object must be explicitly destructed because there is no way for a destruct function to be called when an object goes out of scope. To destruct an object, the destructobject function is called:

destructObject(myObj);

For persistent objects the destructobject function only destructs the object and frees up any memory used by the object in the C binding, it does not destruct any persistent object in the repository. If the object is a transient type, the value of the object is also destructed.

Data Types

Data types are used as the types of properties, and parameters and return values of operations. For some of the UREP data types, the C binding provides a mapping to an equivalent C type. The following list of typedefs shows the mapping between the UREP data type and the C data type. Whenever the UREP data type appears in a model, the corresponding C typedef is used in the C binding.

    ______________________________________
    typedef int           udt.sub.-- boolean
    #define TRUE          1
    #define FALSE         0
    typedef unsigned char udt.sub.-- char;
    typedef long          udt.sub.-- integer;
    typedef double        udt.sub.-- real;
    typedef char *        udt.sub.-- string;
    typedef  const char * udt.sub.-- cstring
    ______________________________________

    ______________________________________
    <type name>
    initd<type name>();
    <type name>
    init<type name>
    (UREP urep
    );
    ______________________________________

    ______________________________________
    <type name>
    copy<type name>
    (<type name> copyObject
    ,udt.sub.-- boolean restricted
    );
    ______________________________________

    ______________________________________
    UrepMetaClass
    initdUrepMetaClass();
    UrepMetaClass
    initUrepMetaClass
    (UREP urep
    );
    UrepMetaClass
    copyUrepMetaClass
    (UrepMetaClass copyObject
    ,udt.sub.-- boolean restricted);
    ______________________________________

    ______________________________________
    <type name>
    init<type name>();
    ______________________________________

    ______________________________________
    <type name>
    copy<type name>
    (<type name> copyObject);
    ______________________________________

    ______________________________________
    <type name>
    convert<type name>
    (<C type> value);
    ______________________________________

    ______________________________________
    UrepInteger
    initUrepInteger();
    UrepInteger
    copyUrepInteger
    (UrepInteger copyObject);
    UrepInteger
    convertUrepInteger
    (udt.sub.-- integer value);
    ______________________________________

    ______________________________________
    typedef enum
    <enumerated type name>.sub.-- <mnemonic 1> ›= <value>!,
    <enumerated type name>.sub.-- <mnemonic 2> ›= <value>!,
     .   .         .
     .   .         .
    <enumerated type name>.sub.-- <mnemonic n> ›= <value>!
    } <enumerated type name>;
    ______________________________________

    ______________________________________
    typedef enum
    UrepCardinality.sub.-- sv = 0,
    UrepCardinality.sub.-- mv = 1
    } UrepCardinality;
    ______________________________________

    ______________________________________
    udt.sub.-- integer
    UrepSystemProfile.sub.-- get.sub.-- maxVariantWidth
    (UrepSystemProfile myself);
    void
    UrepSystemProfile.sub.-- set.sub.-- maxVariantWidth
    (UrepSystemProfile myself
    ,udt.sub.-- integer value);
    ______________________________________

    ______________________________________
    UrepVersionedObject
    UrepCompositeContext.sub.-- get.sub.-- top
    (UrepCompositeContext myself);
    void
    UrepCompositeContext.sub.-- set.sub.-- top
    (UrepCompositeContext myself
    ,UrepVersionedObject value);
    udt.sub.-- boolean
    UrepCompositeContext.sub.-- isNull.sub.-- top
    (UrepCompositeContext myself);
    void
    UrepCompositeContext.sub.-- flush.sub.-- top
    (UrepCompositeContext myself);
    ______________________________________

    ______________________________________
    UrepArray.sub.-- UrepCompositeContext
    UrepVersionedObject.sub.-- get.sub.-- topObjectFor
            (UrepVersionedObject myself);
    udt.sub.-- boolean
    UrepVersionedObject.sub.-- contains.sub.-- topObjectFor
            (UrepVersionedObject myself
            ,UrepCompositeContext object);
    udt.sub.-- integer
    UrepVersionedObject.sub.-- size.sub.-- topObjectFor
            (UrepVersionedObject myself);
    void
    UrepVersionedObject.sub.-- set.sub.-- topObjectFor
            (UrepVersionedObject myself
            ,UrepArray.sub.-- UrepCompositeContext value);
    void
    UrepVersionedObject.sub.-- add.sub.-- topObjectFor
            (UrepVersionedObject myself
            ,UrepCompositeContext value)
    void
    UrepVersionedObject.sub.-- remove.sub.-- topObjectFor
            (UrepVersionedcObject myself
            ,UrepCompositeContext object);
    udt.sub.-- boolean
    UrepVersionedObject.sub.-- isNull.sub.-- topObjectFor
            (UrepVersionedObject myself);
    void
    UrepVersionedObject.sub.-- flush.sub.-- topObjectFor
            (UrepVersionedObject myself);
    ______________________________________

                  TABLE 1
    ______________________________________
    Access and Mutator Function Generation
    Access Mode   Accessors  Mutators
    ______________________________________
    read write    generated  generated
    read only     generated  not generated
    no access     not generated
                             not generated
    ______________________________________

    ______________________________________
    <property type> <type name>.sub.-- get.sub.-- <property name>(UREP
    urep);
    ______________________________________

    ______________________________________
    void <type name>.sub.-- set.sub.-- <property name>
              (UREP urep
              ,<property type> value
              );
    ______________________________________

    ______________________________________
    <type name> <type name>.sub.-- find.sub.-- <property name>
            (<property type> value);
    ______________________________________

    ______________________________________
    <return type> <type name>.sub.-- <operation name>
             (<type name> myself
             ›, <parameters> !
             );
    ______________________________________

    ______________________________________
    UrepVersionedObject
    UrepVersionedObject.sub.-- reserve
              (UrepVersionedObject myself
              ,udt.sub.-- cstring variant
              ,udt.sub.-- boolean reserveComponent
              );
    ______________________________________

                  TABLE 2
    ______________________________________
    Parameters and Return Types.
                                      Input/Output
    Type      Return      Input Parameter
                                      Output Param
    ______________________________________
    udt.sub.-- boolean,
              value (that is,
                          value       pointer (that.
    udt.sub.-- char,
              <type>)                 is, <type>*)
    udt.sub.-- integer,
    udt.sub.-- real,
    enumerated types
    UrepObject (and
              value       value       pointer
    subtypes)
    udt.sub.-- string,
              pointer (already
                          pointer     pointer
    udt.sub.-- cstring
              a pointer)
    ______________________________________

    ______________________________________
           <data type>
           <type name>.sub.-- <operation name>.sub.-- obj
               (<type name> myself
               ›, <parameters> !
               );
    ______________________________________

    ______________________________________
    UrepInteger
    UrepSystemProfile.sub.-- get.sub.-- maxVariantWidth.sub.-- obj
             (UrepSystemProfile myself);
    void
    UrepSystemProfile.sub.-- set.sub.-- maxVariantWidth.sub.-- obj
             (UrepSystemProfile myself
             ,UrepInteger value
    );
    ______________________________________

    ______________________________________
            <return type>
            <type name>.sub.-- <operation name>
                (UREP urep
                ›, <parameters> !
                );
    ______________________________________

    ______________________________________
    void
    UrepPersistentObject.sub.-- destruct
             (UrepPersistentobject myself
             ,UrepReferenceProcessing freeMode
             );
    ______________________________________

    ______________________________________
           UrepPersistentObject.sub.-- destruct(NVO,
           UrepReferenceProcessing.sub.-- objectOnly);
    ______________________________________

• Inventors
  Koerber, Paul Donald;
• Assignee
  Unisys Corp. (Bluebell, PA)
• Published
  Mar-30-1999
• Current US Classes:
  717/108
  717/165
• Application #
  623490
• International Classes
  G06F 009/45
• Field of Search
  395/704 395/707 395/708 395/685
• Examiner
  Toplu; Lucien U.
• Agent
  Richebourg; J. Ronald, Peterson; Steven R., Starr; Mark T.
• US Patent References:
  5421015
  5557776