# Who Could Object?

# Objects: Making Software Smarter

by Jerome Yuzyk jerome@supernet.ab.ca

If you haven't already, you're going to be hearing the word Object-Oriented (O-O or OO-) a lot in the next few years. You're also going to hear that it will Change Your Life, and a lot of other things that will muddy the issue as people learn how to use (and sell) OO-things.

OS/2 has had its own O-O interface since version 2.0, which introduced the WorkPlace Shell (WPS). Your Desktop. Most people think the WPS *is* OS/2, but it's merely one of a number of Interfaces available for OS/2. Unlike the others, though, it introduced a monolithic-sounding acronym in SOM: System Object Model. SOM provides all the programming "nuts and bolts" required to make O-O software like the WPS (and the tools you get in the OS/2 Warp BonusPak).

More than just a library of screen widgets, SOM defines a fundamental method for the way you (as user or programmer) can interact with all the things that make up A Computer. As a live demonstration, IBM used it to create the WorkPlace Shell. Your Desktop.

= Why?

Software is getting very complex. Look at programs you bought 5 years ago to do the things you still do today (write things, crunch numbers, draw pictures). This stuff is getting BIG. A lot of that "bloat" happened because we asked for more and more features for more and more of our hardware, so every program had its own driver for your printer, for example. OS/2 Presentation Manager (PM) came along (and later PM-lite aka the Windows interface) and PM-enabled programs used the system-defined printer (needing only one installation).

Still, we've learned to think about Programs, when what we actually use is Data (or more specifically Information, but we'll leave that for another time). Think of it: your job definition does (or should) *not* include "uses Wordprocessor X," but rather "Creates reports and publications..." O-O software, even in its infancy, removes much of The Program from the way your reach your Data, and finally acknowledges that there are a lot of computer jobs that the machine should really do for you.

= Like...

Figure Out How to Print Something - Why open a Program just to print or fax a document when you can just send the document to the printer?

Manage Your Data "Containers" - Why open a Program to move some Data (Files and related things) around when you can manipulate that Data directly? How about a spreadsheet where cells can be moved around (and adjusted automatically) by being dragged into place?

Ignore the Hookup Details - Redefine a LAN printer in about five minutes (including unpacking and connecting the printer) and never touch more than its server.

Change a Ton of Things in a Wink - Like your desktop subdued and quiet, warm and fuzzy or loud and proud? Change the appearance of your entire system with one Drag+Drop.

= All Right Already, What Are Objects?

From a Webster dictionary I have laying around, an "object" is: "something mental or physical toward which thought, feeling or action is directed."

OS/2 Objects are all over your Desktop. In fact, your Desktop is an Object. How to tell? That's what that little-used Right Mouse Button or Mouse Button Two is for. Click with that button on anything (you will be surprised at what you find), and if it's an Object (and is listening) it should show you a Menu of what it can do.

Take Webster's definition, and you see that a printer is an object, a thing. In the O-O world, give the printer some knowledge about how it does things (its Methods) and it becomes a Printer Object. Give files access to some "knowledge" about how to do "file" things (Methods for creating, deleting, renaming and such), and File Objects can be told to manage themselves.

Objects are like mini-programs, sitting quietly, waiting to be told to do something. The mouse (and keyboard in most cases) is used to send Messages to a Message Queue, like a radio channel. Various Objects tune in to various Queues (though mostly just one, the PM Message Queue) and listen to these Messages, responding if they can. Just about every Object understands the basic mouse-button clicks, for example.

SingleClick DoubleClick Drag Alt-Single -------------------------------------------- Left Select Open -- Rename Right Show Menu -- Move PickUp

Messages can appear in the form of other Objects, so a Printer Object can "understand" what to do when you Drag+Drop an Object onto it. So can Folders (the Desktop too, since it's a Folder). The Sytem Clock can't: it just wouldn't make sense, so it doesn't know how (it has no Methods for handling dropped Objects). Objects make for Easy goof-proofing from a programmer's perspective.

A simple demonstration of this Command-and-Obey behaviour occurs with the Desktop Settings Notebook. Toggle Icon Display from Normal to Small Size and the effects are immediate. Every Object on your Desktop understands the IconSize message and responds to it immediately. In effect, the button on the Settings page shout out "Hey, make your icons small!" to the DeskTop, and all Objects that have icons just do what they're told.

A more dramatic example can be found with the Scheme Pallette. With a simple Alt-Drag of any Scheme to the Desktop (or any other folder) you can completely alter the appearance of your entire system permanently. All Open Folders and Applications will automatically assume a new colour scheme, including menus, window frames, backgrounds, and scroll-bars.

As you look around your system you should notice that there are different "kinds" of objects, usually distinguishable by their Icon. I say "usually" because an Object's Icon is just another feature, and can be changed. The Desktop, for example, doesn't use the standard folder icon even though it's just another (although special) Folder. Objects are generally derived (defined) from Classes. All OS/2 Objects are derived from the WPObject Class, which specifies all the basic characteristics of an Object in a very general sense. With this WPObject definition in hand, several other Classes are defined:

. The WPAbstract Class defines Mouse and Keyboard, Clock, Printer, Shredder and Program Objects

. The WPFileSystem Class defines DataFile and Folder Classes. The DataFile Class defines Objects like Bitmap, Icon and ProgramFile while the Folder Class defines the Desktop, Drives, Startup and Templates.

. The WPTransient Class defines transient Objects like print jobs and LaunchPad events.

Every Object belongs to the WPObject Class, so they have menus and icons. Folder Objects have "special" membership in the WPFileSystem Class because they deal with actual files on disk, and so do "file" things (like show them in Icon, Tree or Details view). The Desktop is a further extension of a Folder.

When you see the SOM Class Hierarchy you might think of a diagram from a Zoology class because Classes are roughly similar, but different enough to be labelled differently. Humans and horses are mammals, so we can expect that they have most of the parts we do: heats, lungs, heads, etc. Humans and horses are different enough to be put in their own classes, though, because no one (meaning us humans who make these things) would miss several other defining features that groups of humans and horses share with each other but not with the other group.

A hierarchical definition of the "things in our world" is very powerful because it provides a very efficient way to collect and organize information. All you need to know about a horse is that it is also a mammal, and if you already know what a mammal is then you know a lot about horses without ever actually seeing one. Knowing that all Objects (can) have a Settings Notebook means that you already have a pretty good idea what to look for in any new Objects you encounter. Knowing that the Desktop is a Folder you means you can treat the Desktop like any other Folder: give it a background, move its Objects around, right-click on its background to get a menu, and so on.

= And Now a Little (sort-of Technical) Detail

[Buzzword Alert: I've tried to keep away from buzzwords but, there are a few that are inescapable. Fortunately, these form the conceptual underpinnings for the whole O-O movement, pre-Marketing, so if you take time to understand them you've got your first layer of "consumer protection armour."]

Objects were first considered about 20 years ago when theorists and practitioners (remember, no PCs then) realized that software was getting large and complex, full of reinvented wheels and little learning accomplished because everyone was always fiddling with the best way to do really fundamental things like reading files and such. 20 years later the mass-market is catching on (as is Mass-Marketing) and Objects are "in." Object-Oriented design is simply an extension of Good Software Design, not a radical departure, except for a generation raised on "DOS (plus whatever) on a PC."

Object-Oriented Design (OOD) involves attention to three key "Prime Directives": Encapsulation, Inheritance and Polymorphism. Big words (and some say mantras), but understanding these three concepts makes the rest of O-O pretty easy. While the initial start-up costs can be high (unless you have no prior bad habits to break or are pretty flexible) the benefits can be enormous.

- Encapsulation

It's nobody's business to know how a printer prints except the printer. Any Printer Object should be able to receive any kind of Object from anywhere and print it appropriately (or advise otherwise).

OS/2 Printer Objects do just that. You can (attempt to) Drag+Drop any Object onto a Printer Object and if it can be printed, it will print using whatever (SOM-enabled) application that was used (and is still available) to create it. If an Object can't "accept" another, it displays a "No Entry" icon and will ignore the Drop. Dropping an Object onto itself does not work simply because Objects almost never know how to "accept" themselves. Not that this leads to any lack of self-esteem, however.

An older version of Encapsulation was Modularity, and the expectation was that software Modules could be snapped into place quickly and easily. The problem was that nobody could figure out what language to speak, and then along came the PC and that changed Software Design into something Everyman could do (and thus anarchy). As the PC world grows up and starts acting more like the old Big Machine people (networking, multi-processing, sharing resources, concerned with security) these old issues are one again Important (meaning in magazines).

At the programming level, Encapsulation means programs can be divided up into specialized pieces, and work "sub-contracted" out to the pieces to be done as they see fit. Like super-subroutines, SOM Objects understand a fixed set of messages and hide all their details (like resource use and memory allocation) from the caller. This can present an enormous amount of Small Looks Big leverage because SOM Objects provide a nearly-free professionally-written library of software for all the tricky stuff like error-checking, interface-building and operating system interaction.

- Inheritance

Have you ever noticed how a Printer Object menu is like a Folder Object menu except that it has a couple extra entries at the bottom? How about opening the Desktop in Tree View or Details View?

Just like you may have inherited "strong hands" or "tallness" from your parents, Objects can inherit traits from a Parent. Unlike many things we inherit from our parents Objects can over-ride what they inherited. SOM Objects are grouped into Classes of similar objects. Printer Objects inherit most of their abilities from the Folder Class and add a couple (or more on a LAN) more features. The WPS Desktop is "sub-classed" from the Folder Class, with a few features removed (like Delete) and a few others added (like Shutdown and Lockup).

Using OS/2 SOM Objects means your work or programming environment inherits all the features available to the system, and as new features are added you inherit them immediately.

. Connecting OS/2 to a network lets your system automatically inherit all the LAN resources you are allowed: new Drives show up in your Drives Folder (a sub-classed Folder), a Network Applications Folder can appear on your Desktop with available LAN-provided Objects, Network Printer Objects accept files.

. OS/2 LAN Server 4.0 uses SOM Objects, adding a menu and status bar to a Folder Object to let you manage Users and Resources as you manage Files. Give a User access to a Resource by Drag+Dropping either Object onto the other. Drive and Folder Objects on a Server (or Peer workstation) inherit file-sharing options when a Server is present.

. Stardock Systems recently released Object Desktop, which can radically alter the operation of the WPS and many other SOM-based applications with code from two floppies. The NPS WPS Enhancer, freeware written by a Japanese TeamOS/2 member, uses 190k of disk space to change the "personality" of the WPS in amazing (and amusing) ways.

- Polymorphism

Drag any Document to the Printer and it should print using whatever printing method is defined for it, or at least use a "default" method. Documents should know how to print themselves, without the Printer needing to be prepared for new types of Objects.

A Printer Object can Modify its actions (call the appropriate application for help) to suit the Objects it receives. It can just as easily print Mesa/2 spreadsheets as it can AmiPro documents. Just Drop things onto a Printer and it handles the rest.

Polymorphism is the ability for an Object to have multiple personalities, adapting to the Messages it receives and changing its character to suit data that it may have not been specifically designed to understand.

= Keener Stuff: Technical Trivia

- Want to see some Object definitions?

Look in c:\os2\ini.rc at line 110, for the deinitions of the basic OS/2 Objects. While you're at it, look in the other .RC files to see a few other ways that the WPS can be defined. All the Classes I mentioned above are actually called WP-whatever. The Information Folder is an Object of class WPFolder, located on (which usually points to C:\DESKTOP) with an ID of .

For a closer look you'll need some tools. Most OS/2 programming language packages have a Class Browser, required to decode the data that makes up Class and Object definitions. You can browse the OS2*.INI files with some freely-available tools like IniMaint or other INI editors. But beware: if you make a mess with one of these tools you have some serious work ahead to repair things.

- Objects Under the Hood

In OS/2, Object thinking has been taken to deeper levels than just the user interface. Programs allocate Memory Objects, which are logical "chunks" of total system memory. Memory Objects are marked in several ways for housekeeping purposes, including whether they are private or shared (and by who), how much is actually in RAM, and how that RAM is allocated.

- Over-ride the Default Menu Style

For OS/2 Warp at least, put the line

SET MENUSTYLE=SHORT

in your CONFIG.SYS, re-boot, and you'll notice all your object menus are (drastically) shorter.

- Keep your Objects Awake Longer

Objects use a certain amount of memory. After use, an Object is kept in memory for a certain amount of time before its memory is released back to the system, 90 seconds by default. This interval is called OBJECTSNOOZETIME and can be SET from CONFIG.SYS. You can "see" this interval if you have a laptop that can turn off its hard-disk to save power. After a while, Desktop Objects like the LaunchPad are flushed out of memory and must be re-read from disk, and even passing your cursor over the LaunchPad will cause your disk to wake up.

= A Very Important Side-Effect of SOM-like design

In OS/2, file references are ID-based. File Name (and thereby location) is merely an attribute (like Icon or Creation Date). Thus, a file moved in a SOM-based manner automatically updates any references to it on that system. DSOM, the Distributed form of SOM, extends this portability out to the network (and thereby the world).

There is another system, used by others, that builds its links using File Name references (and thereby locations), and must re-establish those references by searching all available file storage, even across a network, every time an object is moved. You can imagine what might happen if this search finds a different (though same-named) copy of that file. Also imagine what happens when that file is linked to others.

Expect users of SOM-based systems to have a lot more fun with Objects as they plan where they're going Tomorrow, rather than just where they're going Today.