Access modes provide the ability to hide or expose class members to other parts of an application based on how the class member is defined. Class members include variables, properties, methods and events which are common to object-oriented programming languages and ABL resources like buffers, temp-tables, datasets and queries. The available access modes from most to least restrictive are:

  • PRIVATE - Limits access to the class.
  • PACKAGE-PRIVATE - Limits access to the class and any class within its package.
  • PROTECTED - Limits access to the class and subclasses of the class.
  • PACKAGE-PROTECTED - Limits access to the class, any class within its package, and to any subclass that inherits from the class.
  • PUBLIC - Accessible to all.

In ABL, a package is the directory structure, relative to the PROPATH leading up to the class itself, as specified in the CLASS statement. This directory path identifies the location of the file that defines a class, interface, or enumeration. PACKAGE-PRIVATE and PACKAGE-PROTECTED restrict access at the package level.

The following table identifies whether a specific access mode exposes a class member to other parts of the application.
Access mode Class Subclass Package All
PRIVATE Y N N N
PACKAGE-PRIVATE Y N Y N
PROTECTED Y Y N N
PACKAGE-PROTECTED Y Y Y N
PUBLIC Y Y Y Y

See the ABL Syntax Reference in ABL Reference for available access modes and default values for each class member.

See the ABL package-level access modes video in OpenEdge Videos for more information on the PACKAGE-PRIVATE and PACKAGE-PROTECTED access modes.

Best practices

A commonly held object-oriented best practice is making code open to extension and closed to modification. As a developer, picking the right access mode is critical. The compiler enforces access modes so if access is denied to other parts of the application then a conversation between developers is required to relax the restriction by changing the access mode. The general guideline is to begin with the most restrictive access mode and build valid use cases for relaxing the access restrictions.
  1. Always be explicit in defining an access mode.
  2. Use PRIVATE to ensure class members can only be accessed by the class.
  3. If a class member is required by other classes in the class hierarchy, use PROTECTED.
  4. Organize class, interfaces and enumerations in named packages for components, frameworks or libraries. Use PACKAGE-PRIVATE or PACKAGE-PROTECTED access modes to limit access based on the named package.
  5. Avoid PUBLIC, unless the intent is for anyone from anywhere to access the class member.