Properties and Constants

This section discusses the various ways to use properties and constants with application classes.

A method is a procedure or routine, associated with one or more classes, that acts on an object.

A property is an attribute of an object.

PeopleSoft recommends that you use read/write or read-only properties instead of creating methods named GetXxx and SetXxx. For example, instead of creating a method GetName, that takes no parameter, just to return the name of an object, create a read-only property Name.

If your properties simply set or return the value of an instance variable, it is far more efficient to declare the property that way than have a get and set method. The overhead of having a get and set method means that each time the property is reference some PeopleCode has to be run.

Application classes can have read-only properties, but no indexed properties.

Considerations Creating Public Properties

There are two implementations of (public) properties:

  • as instance variables.

  • as get-set methods.

From outside the class, you cannot tell the difference between them (for example, both are dynamically bound). However, if you just want to expose an instance variable to users of the class, you can declare a property of that name and type, which declares the instance variable too: 

class xxx
     property string StringProp;
end-class

If you want the property to be read-only outside the class, use the following code:

class xxx
     property string StringProp readonly;
end-class

Both of these code examples declare an instance variable called &StringProp and provide its value for getting and change its value for setting (if not readonly). You can think of this as shorthand for the usual implementation of get-set methods.

If you want to implement the same with code (perhaps deriving the property from other instance variables or other data), use the following sort of PeopleCode program:

class xxx
   property string StringProp get set;
   
private
   instance string &inst_str;
   
end-class;

get StringProp
   /+ Returns String +/
   Return &inst_str; /* Get the value from somewhere. */
end-get;

set StringProp
   /+ &NewValue as String +/
   /* Do something with &NewValue. */
   &inst_str = &NewValue;
end-set;

To specify a read-only property, omit the set portions of the code example.

A property of a superclass can be overridden by a subclass by providing a different implementation.

The properties of a class are implemented by the keywords Get and Set, or by access to an otherwise private instance variable.

To access the property, you do not have to specify Get or Set: the context tells the processor which task you're doing. To create read-only properties, specify only a Get method, with no Set method, or for instance variable properties, specify Readonly.

For an instance variable property, there are two different ways for method code in the class itself to refer to the property:

  • %This.PropertyName

  • &PropertyName

The first way is dynamically bound, as it uses whatever (possibly overridden by a subclass) implementation of PropertyName that the current object provides.

The second way always accesses the private instance variable of the class that the method is declared in.

The following example returns strings, by converting the property. It also demonstrates overriding.

class A
   property number Anum;
   property string Astring get;
   property string Astring2 get;
end-class;

/* The following is a dynamic reference to the Anum property of the current object, which might be a subclass of A, so this might not access the A class's implementation of Anum as an instance variable. */
Get Astring
   return String(%This.Anum);
end-get;

/* The following is a static reference to our &Anum instance variable. Since it does not use %This, it will not be overridden even if the current object is a subclass of A. */
Get Astring2
   return String(&Anum);
end-get;

/* The following overrides the Anum property of our superclass, 
in this case by providing another instance variable implementation. 
This gives us our own &Anum instance variable. */
class B extends A
   property number Anum;
end-class;
. . .
/* Set the Anum property in B. Because of the above definitions, this sets 
the &Anum instance variable in the B object, but not the &Anum instance 
variable in its superobject. In the absence of other setting, the latter will 
be defaulted to 0. */ 

local B &B = Create B();
&B.Anum = 2;

&MyValue = &B.Astring; /* &MyValue is "2" */
&MyValue = &B.Astring2; /* &MyValue is now "0" */

PeopleSoft recommends against defining properties that are public and mutable in application classes (similar to public instance variables) because this allows external code to read and change the internal state of the object without any controls. Instead, modify the property declarations with the Get and Set keywords.

There is a slight performance advantage, and you write less code, if you use the Get and Set keywords over using get and set methods.

If you define a property with the Get and Set keywords, you also must define a get or set block in the same part of the code that contains the method bodies.

PeopleCode read-only properties are functionally similar to static variables, as long as the class that defines the properties initializes them and does not change them. The difference is that you need an instance of the class to access them.

For example, consider a Category object that has a CategoryType member that can have one of the following values:

  • ‘R’ for Regular

  • ‘B’ for Browse

  • ‘N’ for News

You can define three read-only properties corresponding to each of these values, REGULAR, BROWSE, and NEWS, then initialize them to the appropriate values in the constructor of the class.

When you write code to evaluate the CategoryType of the Category object, perform a test like this: 

If (&category.getCategoryType() = &constants.NEWS) then...

PeopleSoft recommends referring to the read-only properties, rather than their literal values, for the following reasons:

  • If you spell a literal value incorrectly, the PeopleCode editor does not catch it; if you spell a read-only property wrong, it does.

  • If you ever need to change the value of a read-only property, you only have to do it in one place.

  • It makes the code more maintainable and reusable (because NEWS is more intelligible than ‘N’).

Application classes can contain collections. Collections of objects generally have at least the following methods and properties.

  • First()

  • Item(Index)

  • Next()

  • Count (as a property)

All numeric indexes in PeopleCode are one-origin, that is, start all indexes at 1, not 0.

PeopleSoft recommends that if constants are inextricably linked to a class, you should define them within that class. If the constants are more general, potentially used by multiple classes, consolidate the constants into a constants class at application-level or package-level.

Message catalog set and message numbers are good candidates to centralize into a single constants class. It can improve the readability of code and make it easier to maintain these values.

For example, you can define a constant MSG_SET_NBR, and then define constant values for each message that explain a little about what the message represents (like REQUIRED_VALUE_MISSING, UNIMPLEMENTED_METHOD, or INSUFFICIENT_PRIVILEGES).