Overloading also enables you to provide additional flexibility to programmers using an object type. Consider the building object type defined in Listing 13.7. It has a method named ChangeMgr, which allows you to specify an employee who is the building manager for a building. This method takes one argument, the employee number. What if you also wanted the ability to specify the manager by name? One solution would be to write a method named ChangeMgrName to do this, but then you would have to constantly remember which method to call each time you wrote code to change a building manager. Worse, you might get confused about the naming convention and try writing a call to ChangeMgrNo, or perhaps to ChangeMgrEmpNo, neither of which exist. Instead you can simply declare another member function named ChangeMgr, but with a string argument instead of a number. This function would look up the employee by name, get the employee number, and store that number as an attribute. Oracle would know to call this new version of the method when you supplied a string argument, and would know to call the old version of the method when you supplied a numeric argument. The advantage to this is that when you are coding, you always call ChangeMgr whenever you need to specify a new building manager, regardless of whether you are specifying the new manager by name or number.

Comparing Objects

Are two objects equal? Is one "greater than" another? How do they compare? Sooner or later you will want to write code to answer these questions. Before you can do that, you must decide on the comparison semantics. What is it about two building objects, for example, that makes one "greater than" another? This is often not as simple a question as it might seem at first. When dealing with numbers, common convention dictates that the number with the larger value is "greater than" the other. But when dealing with buildings, what attribute do you consider? You could, for example, look at how high the building is. A taller building would be "greater than" a shorter building. Alternatively, you could look at the "footprint" of the building, basing your decision on the number of square feet of ground space that the building occupied. Another alternative would be to base the "greater than" decision on the total square footage of the building's floor space.

As you can see, even with a type as simple as the building type, there are many alternatives to look at when considering how comparisons should be done. The choice might ultimately become somewhat arbitrary based on how you intend to use the object.

To help you compare objects, Oracle allows you to declare two special member function types. These are identified by the keywords MAP and ORDER. A MAP function enables you to specify a single numeric value that is used when comparing two objects of the same type. The greater than/less than/equality decision is based on this value. An ORDER function enables you to write whatever code you want in order to compare two objects, the return value indicating equality or which of the two is greater.

The ORDER Method

You might have noticed back in Listing 13.7 that the keyword ORDER was used in front of one of the member functions for a building. The specification for that function looks like this:

ORDER MEMBER FUNCTION Compare (OtherBuilding IN building)
      RETURN INTEGER

The keyword ORDER tells Oracle that Compare is a specially written function that should be called whenever it is necessary to compare one building object with another. It takes one argument, which must be of the same type. In other words, because Compare is a method of the building object type, the argument to Compare must also be of the building object type.

Remember that every object method has a default first argument named SELF, and that the SELF argument represents the object whose method was called. An ORDER function is expected to compare SELF to its argument and return one of the values shown in Table 13.1.

Table 13.1. ORDER function return values.

After you have defined an ORDER function for an object type, you can then use any of the

PL/SQL relational operators with objects of that type. Listing 13.17 instantiates some building objects and shows the result of some simple comparisons.

Listing 13.17. Comparing objects with ORDER functions.

 1: SET SERVEROUTPUT ON
 2: DECLARE
 3:   bldg_a      building;   --will be less than bldg_b
 4:   bldg_b      building;
 5:   bldg_b2     building;
 6:   bldg_c      building;
 7: BEGIN
 8:   --First, create four building objects.
 9:   bldg_a := building(`A Building',null,null);
10:   bldg_b := building(`Another Building',null,null);
11:   bldg_b2 := building(`Another Building',null,null);
12:   bldg_c := building(`Cosmotology Research Lab',null,null);
13:
14:   --Now compare the building objects and display the results;
15:   IF bldg_a < bldg_b THEN
16:     dbms_output.put_line(`bldg_a < bldg_b');
17:   END IF;
18:
19:   --These two have the same name, so should be equal.
20:   IF bldg_b = bldg_b2 THEN
21:     dbms_output.put_line(`bldg_b = bldg_b2');
22:   END IF;
23:
24:   IF bldg_c > bldg_b2 THEN
25:     dbms_output.put_line(`bldg_c > bldg_b2');
26:   END IF;
27: END;
28: /

bldg_a < bldg_b
bldg_b = bldg_b2
bldg_c > bldg_b2

PL/SQL procedure successfully completed.