BBj Custom Objects Tutorial: Fields

The fields of a custom object class represent the data for that class. Fields are strongly typed — each field explicitly requires a type as part of its declaration. As an example, here is a declaration for a field that will hold the unique identifier for a Book class:

Sample 4. Fields in a Book Class

BBj’s field verb is only valid inside of a custom object class definition, and must be outside of all of that class’s methods.

Each field of a custom object class must have an explicitly defined access level. Field access levels can be any one of three values:

• private – the field can only be accessed by methods of the class (the field has class scope; this is the most restrictive access level)

• protected – the field can be accessed by methods of the class AND by methods of any class that extends this class (any subclass)

• public – the field can be accessed by methods of the class AND by methods of any subclass AND from code outside of the class (this is the least restrictive access level)

In the example above, the ID and Title$ fields both have an access level of public.

Each field of a custom object class has a type. In the example above, the ID field has a type of BBjNumber, a built-in BBj custom object class. The Title$ field has a type of BBjString, another built-in BBj custom object class.

Each field of a custom object class must have a valid name and the correct suffix (see Types in BBj for details). In Sample 4, the variable names are:

ID	No suffix needed because the type is BBjNumber
Title$	A “$” suffix because the type is BBjString

The last text in the Title$ field declaration shows that fields can have an optional initialization expression (an initial or default value). If there is no initialization expression (as with the ID field), then the initial value is dependent on the field’s type:

Field Type	Initialization Value
BBjString	An empty string ("")
BBjNumber	0
BBjInt	0
All other fields	null

For more details about defining and using fields, see FIELD Verb.

Accessing a Field

There are two models for accessing a field of a custom object class: external and internal access. In both models, the fields of a custom object are not accessed with the dot notation that is common to other object-oriented languages. Let’s examine the access model in each case.

External Access – Accessor Methods

The fields of a custom object cannot be accessed directly from outside of the class. Instead, code outside of the class accesses the fields by using their accessor methods. BBj automatically generates two accessor methods for each field named X:

• getX()

• setX(typeOfX arg1)

These accessor methods have the same protection level as the fields being accessed. For example, BBj will implicitly generate the following accessors for the ID field from Sample 4:

Sample 5. Automatically Generated Accessors

These methods will not actually exist in code anywhere – they are implicit, like the default constructor method mentioned earlier. They are only available if you do not explicitly define your own accessors with the same signatures. If you need different actions to occur when getting or setting the ID field, you can explicitly define either one or both of these accessors, and replace their actions with your own.

Internal Access – the # Prefix

The fields of a custom object can be accessed directly inside of the class by prepending a # character to the field name. Code in the class can directly access any of its fields, including any protected or public fields of its superclass, with this model.

In Sample 5 above, you probably noticed the # sign in front of the ID field in both accessors. The special symbol # is required in front of a field name in order for a custom object method to get direct access to a field (bypassing the accessor methods). Within a method such as the setID() method, the code uses #fieldName (in this case, #ID) to access the field.

Special Fields in Classes

Custom object classes have one or more special fields that BBj implicitly defines for you. Let’s look at each of these fields.

Static Fields

There is an optional keyword, static, that can be inserted between the access level (public in Sample 5) and the field type (BBjNumber in that example). Fields like ID, that do not have the keyword static, are instance (or non-static) fields.

Static fields are special: they are shared by all instances of the class. If the ID field were static, then whenever one instance of the Book class set the ID field, all instances of the Book class would share that same value. It should be obvious why the ID field is not static—each Book needs its own unique ID value.

Some points to remember about static fields:

• The implicit accessor methods that BBj creates automatically for public static fields are public static methods. They are invoked following the model for any static method (see the section on Static Methods).

• Static fields can be used in static methods of the class.

• Static fields can be used in instance (non-static) methods of the class.

• Any class can have one or more static fields.

• Static fields are shared between all instances of that class.

The this! Field

Every custom object has an implicit field with the name this!. The this! field is another way to refer to “this particular instance of this class”. One common use of the this! field is as an argument to some other class’s method that takes an instance of “this class”. You are unlikely to need the this! field until your code reaches advanced levels.

Some points to remember:

• Code in any instance method of the class (any method that is not static) can access this implicit field using #this!. Because this! is a field, you must use the # prefix to refer to it.

• The this! field is only accessible to code in this class’s instance methods. It is not available to code in static methods of the class, and it is not accessible from outside of the class.

• BBj does not implicitly generate a getThis() or setThis() accessor as it does for most other fields.

• The this! field is not editable.

The super! Field

If a custom object class extends another class (it is a subclass, and it has a superclass), then the subclass has a second implicit field with the name super!. Inside the subclass, you can use the super! field to refer specifically to the superclass instance. You are unlikely to need the super! field unless your code is at an advanced level.

Some points to remember:

• Code in any instance method of the subclass (any method that is not static) can access this implicit field using #super!. Because super! is a field, you must use the # prefix to refer to it.

• The super! field is only accessible to code in the subclass’s instance methods. It is not available to code in static methods of the subclass, and not from outside of the subclass.

• BBj does not implicitly generate a getSuper() or setSuper() accessor as it does for most other fields.

• The super! field is not editable.

Next Step: Methods

BBj Custom Objects Tutorial Contents

BBj Custom Objects Tutorial: Introduction

BBj Custom Objects Tutorial: Interfaces

BBj Custom Objects Tutorial: Classes

BBj Custom Objects Tutorial: Fields

BBj Custom Objects Tutorial: Methods

BBj Custom Objects Tutorial: Using Custom Objects

BBj Custom Objects Tutorial: Program #1 - Writing a Check

BBj Custom Objects Tutorial: Program #2 - Protected and Private Fields

BBj Custom Objects Tutorial: Program #3: The Static Keyword

BBj Custom Objects Tutorial: Program #4 - Error Handling

BBj Custom Objects Tutorial: Program #5 - Class Inheritance

BBj Custom Objects Tutorial: Program #6 - Callback Choices

BBj Custom Objects Tutorial: Program #7 - Constructors and Field Initialization