&os2;'s Workplace Shell (WPS) is frequently described as "object-oriented". This term suggests that -- as opposed to the user interfaces of other operating systems -- everything the Workplace Shell deals with is first considered an "object": this applies, for example, to &link_folders;, &link_datafiles;, printers, drive objects etc. All these objects have certain common characteristics (such as &popmenu;s and properties notebooks), but differ in certain others: for example, what you see in a &popmenu; depends on the selected object.

In order to better handle these common and different characteristics, the WPS uses "classes". This term has been taken from object-oriented programming; a class is, so-to-say, an abstract concept, or a template, for an object. A class is therefore not visible on the Desktop, it thus does not "exist" in the same sense as objects do, but it contains all the information about properties and capabilities of an object and the executable code to make an object do something.

All WPS classes reside in dynamic link libraries (DLLs). For example, most of the default WPS classes reside in the large PMWP.DLL file in the \OS2\DLL directory. All &xwp; classes reside in XFLDR.DLL in the &xwp; installation directory.

Now, every object on the Desktop is a so-called "instance" of some class. The names of most of the WPS classes start with "WP": for example, a printer is an instance of the "WPPrinter" class, a folder one of the class "WPFolder", a datafile of "WPDataFile" and so on.

The reason for the power and flexibility of the class concept is that the different classes may descend from each other. Such a descendant class will inherit all of the properties and capabilities from its parent class. It is thus possible to make certain features of the user-interface more abstract, according to the old principle: the best way to handle complexity is abstraction.

The WPS contains many classes, which make up a very thoughtful inheritance hierarchy. The following excerpt from the WPS class list may make the general structure more lucid (where the lines represent parentship):

 WPObject
   ÃÄÄ WPAbstract
   ³     ÃÄÄ WPPrinter
   ³     ÃÄÄ WPProgram
   ³     ÀÄÄ WPShadow
   ÃÄÄ WPFileSystem
   ³     ÃÄÄ WPDataFile
   ³     ³      ÃÄÄ WPIcon
   ³     ³      ÀÄÄ WPProgramFile
   ³     ÀÄÄ WPFolder
   ³            ÃÄÄ WPDesktop
   ³            ÀÄÄ WPStartup
   ÀÄÄ WPTransient
You see that all classes are descendants of WPObject, which is therefore called the "root class" of all WPS classes. This implements all the features that are common to all Desktop objects: as mentioned before, e.g. &popmenu;s and properties notebooks. However, the WPObject class is too abstract to have instances of it: this class was only implemented to have other descendant classes. Objects of this class will not function.

WPObject has only three descendant classes. All these classes are -- like WPObject -- only meant to be abstract parent classes, of which no objects should exist directly.

  1. WPAbstract is the common parent class for so-called "abstract" objects, i.e. those objects which do not physically exist on disk, but only store their data in OS2.INI. The most well-known examples for this are the classes WPPrinter for printer objects, WPProgram for program objects, and WPShadow for shadows. All these objects can appear in folders, but are not visible if you enter DIR at the command line, for example.

  2. By contrast, WPFileSystem is the common superclass for objects which do exist physically in a file system of a drive. There are two subtypes: folders (WPFolder class) and data files (WPDataFile). In turn, there are several subclasses of WPDataFile, like WPIcon for icon files and WPProgramFile for program files (executables, usually with the .EXE extension). All data files for which no more specific subclass exists are instances of WPDataFile.

  3. Finally, WPTransient is used by the WPS for objects which need not save their data at all, but only exist temporarily for representing something. Examples of this are print jobs in a printer object and all the devices in the Hardware Manager.
The WPS also offers an exceptional mechanism called class replacements. This feature is used extensively by &xwp; to hook all of its features into the WPS by replacing a number of standard WPS classes. For example, the XFolder class itself replaces the WPFolder class to implement all the new folder features.

Such a replacement class must always be a descendant of the class which it should replace; "replacing" the class then means that the WPS will always use the replacement class whenever the original class would normally be used. As a result, if &xwp; is installed, all folders of your system are no longer instances of WPFolder, but of XFolder. But since XFolder is a descendant of WPFolder, all standard folder characteristics are inherited and still exist with the folders on your system.

Using class replacements enables programmers to implement new features for a class without having to know in detail how a certain class works internally. This is an outstanding and powerful concept, which is unmatched by other operating systems.

If you open &xwp;'s "WPS Class List" object, all of the classes installed on your system will be displayed. Regularily, these will be more than 100 classes, which will appear in a tree structure. Using &popmenu;s, you may register and replace classes here and also deregister classes and undo class replacements. Also, you can attempt to create an object (that is: an instance) of many classes on your Desktop.

Please note that you should be very careful when manipulating the WPS class list. By making the wrong change, you can make your system unusable!