Sure. Think about it: Toss a rock in a pond and circles of waves will fan out from the point of impact, eventually to lap at the opposite shore. They're waves -- in water. Clap your hands and sound waves carry the rhythm to the folks across the room. Those are waves in air. But radio waves can cross the gulfs between galaxies, where there's as close to nothing as anywhere else you could name. Waves in what? The only truthful way to answer that question is to cop out and contend that radio waves aren't really waves at all, they're, well, they're quantum phenomena, which is just God's way of telling us, because I Say So.

Over the past year, an uncomfortable truth has been dawning on me, as I've experimented with objects in different languages and different applications. The truth is that we've been missing something essential in thinking about objects, or, worse, pretending that that something isn't necessary and doesn't exist. The something I speak of is the larger context within which objects are used. In an admittedly loose analogy, if objects are waves, then their context is what they, as waves, are made of.

We've been very quick to shout about how objects are casehardened little nuggets of functionality, totally encapsulated and independent of other program elements. We've bragged about how the coupling between objects and other program elements approaches zero. We've even been extrapolating from our own hype, and claiming that objects will eventually be the software equivalent of TTL integrated circuits (this is a Brad Cox notion to which I'll return later on) and will be available off-the-shelf in hundreds of different standard "packages" that anyone can buy and use. We've been generating all this yahooha without thinking too hard about how objects interact with their context, and how that context shapes and limits what may be done with its objects.

In all but a few DOS OOP languages, an object's context is, in practice, limited to the language that generates the objects. Can you stick a compiled Turbo Pascal object on a disk and hand it to a friend who programs in Turbo C++? It's supposed to be possible (with some restrictions) but hey; judging by the hOOPla, you'd expect it to be easy.

The new release of JPI's TopSpeed Environment allows much greater sharing of objects across languages. JPI has carefully defined a language-independent calling convention, and all languages share a common runtime library. In theory (and I haven't tested this rigorously), any compiled JPI object should be usable from any JPI object-oriented language.

This tells us something about objects that should be obvious -- and yet how soon we forget: An object is no less dependent on its language's runtime library than any compiled subprogram. We can't even write an object to a disk file without elaborate and (to my mind) somewhat shaky fooling-around, because when the object goes to disk, its code doesn't go with it. The code stays in a library module of some kind, and only instance data is written out to a stream. Registration with a stream only allows the object to locate its code in a code segment when the object is read back from disk to memory. Encapsulation here is more a matter of calling rights than any sort of physical bundling-up-in-a-ball, as too many of us have uncritically come to assume.

If we as a community have misunderstood one element of object-oriented technology more than any other, I would have to point to the object hierarchy context as the culprit. This is the origin of that old objection of Scott Guthery (DDJ, December, 1989) that even if you just want a banana, you get the whole gorilla. And if you're dealing with a sizeable object hierarchy, he's right -- you can't necessarily just pick one item off an object hierarchy tree without the risk of bringing along a lot of unexpected baggage. Scott was reminding us that encapsulation includes everything on a line between the root and the particular leaf you instantiate. In other words, once you invoke inheritance, no object is a banana.

Rather, I think it's fair to say that the object is the hierarchy, and that if you link an object into your application, you link in much or most of its hierarchy and all of the hierarchy's assumptions as well. Linkers can only get so smart, and if you make heavy use of polymorphism and virtual methods, little or nothing will be stripped out of the hierarchy at link time. This will be true even if all you intend to use is one or two different classes from the tree.

The logical extreme of hierarchy context is seen in Smalltalk, where there is only one hierarchy, and everything is part of that hierarchy. In Smalltalk, there is only one indivisible gorilla, and an individual class is nothing more than the gorilla wearing a hand puppet. You can watch the puppet and ignore the gorilla, but you must not forget that the gorilla is always there, and that without him, the hand puppet is limp and useless.

Does it sound like I've become a little disenchanted with objects? I suppose I have. The Object Wave is a little more than two years old now, and it came about with a truckful of promises, few of which have been fulfilled. One promise in particular attracted me, and I've come around to the bitter view that we just can't get there from here.

That was the promise of standard, universally usable software mechanisms made possible through object-oriented technology. I first encountered this promise in Brad Cox's very good book, Object-Oriented Programming: an Evolutionary Approach. The book was in one respect an apologia for Cox's own language, Objective C, but it was also a call to produce what Cox calls (and has trademarked as) Software ICs.

For the last 15 or 20 years engineers have been able to make use of a vast array of digital logic blocks created as TTL integrated circuits. The logic blocks are all different, but what remains universally standard is the way the blocks interact. All chips use a standard power potential of five volts, and all input and output pins have a standard voltage swing and current source/sink ability called fan-in and fan-out. Several dozen companies make or have made TTL ICs, and all of them may be used interchangeably, regardless of their vendors.

Why can't we do this with objects? Simply put: There is no standard context. The standard context of TTL ICs is simple and universal: the laws of electrical physics, bounded by a spare handful of standard assumptions about voltage and current values.

The best we can do so far is create standard object libraries for use with particular compilers. Object Professional and Turbo Vision are good examples. But hey, what's the essential difference between object libraries like that and the garden-variety procedure and function libraries we've been using for years? The answer: Not much.

There is promise for creating language-spanning object libraries for JPI's TopSpeed system, but that's no consequence of OOP technology; you could do the same with ordinary procedures and functions.

If there is a solution -- or at least a next step -- it will have to be the broadening of object contexts to embrace the platform, regardless of language. DOS as we know it is hopeless in that regard, because it can only reliably treat a piece of code as an executable stored on disk. (DOS's sole motion toward what I have in mind involves TSRs, which are thoroughly crippled by DOS's careless internal architecture. A TSR object library, while theoretically possible, has to jump through flaming hoops to keep itself from crashing the system. Not cool.) The platform must be able to treat a binary image containing both code and data (that is, an object) as a loadable library that can be made safely available to all transient applications.

Surprise! We're halfway there, and what Microsoft does in the next two years will dictate how close we will eventually come.

The underlying machinery for a language-independent, platform-wide object context has been with us since the release of Windows 3.0. I'm talking about Dynamic Link Libraries (DLLs), perhaps the least-appreciated feature Windows brings us. DLLs are a little like units, and a little like TSRs. Like units, they can contain both code and data, and they can have an initialization section (but not an exit procedure). Like TSRs they can be loaded by Windows and ;left in memory for the use of other programs. They occupy the same ecological niche under Windows that TSRs occupy under DOS: that of resident platform extension. Windows itself is composed of several DLLs that are loaded by the Windows kernel when Windows takes control, so in creating a DLL you are in a sense extending Windows.

What DLLs do not have is any high-level knowledge of object-oriented methods. This is the missing half that must be added, and again, it's a conceptually simple matter of defining some standards. There is a movement underway at Microsoft to define some of these platform-wide, object-interface standards, but one gets the impression that real technology is still years off. I suspect it probably wont be incorporated into a Microsoft platform before the 32-bit Windows descendant expected (by this columnist at least) no earlier than September of 1993.

Once a tenable platform object context appears as Win32, a great deal more of the promise of OOP should become real. We should be able to pass "canned" objects from machine to machine on disk or over networks, and expect them to work identically on all Win32-based machines, from any language that supports the standard object messaging protocol.

That path wont get us to the non-Win32 machines, but shall we say this doesn't distress me. At the rate big hardware companies like Apple and IBM continue to slit their own throats, I anticipate that by the turn of the century the Gruesome Twosome will be reduced to a couple of niche firms offering special-purpose, high-end boxes and paying their bills by selling Pacific Rim 80686-based PC clones. Nope. Software rules the future, and you and I both know who rules software, with no serious challenger in sight.

I said all that as my way of announcing that I am ceasing my search for object-oriented truth and will instead settle for a good toolbox. Because that's where I've found object technology to really shine: in the design of software tools that may be easily extended and customized without gross rewriting of source code.

Good examples are beginning to appear, now that developers have digested and understand object technology. For the next several columns I'll be probing Turbo Vision, which comes in the can with Turbo Pascal 6.0 and is probably the most-owned (if not necessarily the most-used) object-oriented toolbox going right now.

Turbo Vision has taken a lot of heat on the networks and in the user groups since it appeared. It's quite literally unlike anything Borland has ever released for Turbo Pascal, and it really does represent a new turn in technology, not only for Turbo Pascal but for Pascal in general. A lot of people hate it. Few people truly understand it. But I would like to plead for everyone to see it on its own terms and give it a fair chance.

I'm not really stealing a phrase from Chapter 1 of the Turbo Vision Guide when I say that Turbo Vision provides the bones of a windowing application. I wrote some early parts of the Guide, and I like that way of putting it: Turbo Vision allows you to inherit the bones of an application (things such as menus, windows, edit fields, and so on) to which you add the meat, which are the routines that allow the application to do your specific tasks.

It isn't quite accurate to call TV a user-interface toolbox. It's really a boilerplate application, stripped of all application-specific functionality. The most visible portions of TV are UI components, obviously -- but behind the scenes are some other remarkable mechanisms as well. Turbo Vision contains a very efficient event manager that lets you break away from the "pick a number from the menu" kind of hierarchical control that leads to what I called The Cuba Lake Effect a few columns back. All of this is built into a remarkable object type called TApplication, which is the boilerplate application I spoke of earlier.

From a height, this is how you use Turbo Vision: You create a child type of TApplication. You override some of its existing methods and add some new methods; add a few other objects, define some menus and dialogs, and hook the various parts together with pointers. That's your application; and your main program looks like this in almost every case:

BEGIN
   MyApplication.Init;
   MyApplication.Run;
   MyApplication.Done;
END.

The first line sets your application up. The second line runs it. The third line reasserts system defaults, deallocates memory, and otherwise tidies up whatever mess the application made.

I won't be so bold as to say it's simple, nor that it's easy. Turbo Vision was certainly the most difficult learning experience I ever had in Pascal, so if you're having trouble with TV, don't kick yourself for it. Nonetheless, for all the trouble I've had with it (and am still having with it!) I continue to use it and like it more and more as I do.

I see Turbo Vision as something like a pair of expensive leather boots. They hurt when you first put them on, but as you wear them two things happen: The boots adapt to your feet, and your feet adapt to the boots. You need to use TV intensely for a while to make it stop hurting -- because the hurt comes from not truly understanding what the damned thing is up to, nor how to make it do what you want. As you become familiar with Turbo Vision, however, the pain goes away, not only because you understand how it works, but also because understanding how it works allows you to bend it in your own directions to suit your own needs. Over time, it becomes a far better fit -- and eventually, you'll wonder how you ever did without it.

I've managed to distill some guidelines for working with Turbo Vision. These are the "rules," in a sense, and if you're not willing to play by the rules you'll be in a rut and wearing the tread off your tires in no time.

1. Understand pointers. Really. I mean, really really. If you aren't comfortable with pointers, TV will be a brick wall ten miles high. Polymorphism depends utterly on pointers to make it work, and TV makes the most pervasive use of polymorphism that I have ever encountered.
2. Don't try to subset it. You can't just pull a menu procedure out of Turbo Vision and use it apart from TApplication. TV isn't really a toolbox from which you can pick one gizmo or the other. It's a boilerplate application, and the explicit and implicit coupling among the components is very high. About the only thing I would say is extractable from Turbo Vision is the TCollection hierarchy, which is basically a linked-list manager that functions tolerably well on its own.
3. Don't try to modify it. In other words, extend it but don't try to alter the look or operation of the parts that are already there. The coupling among the components is high, and this coupling is not simply a matter of procedure calls or global variables. There are a multitude of very subtle assumptions underlying Turbo Vision, (most of them completely undocumented) and even innocuous-appearing changes can have completely unexpected consequences in what seem to be totally unrelated parts of the system.
4. Do things the Turbo Vision way. Whenever you can, let Turbo Vision carry the ball its own way and in its own direction. All of us have our own ways of thinking about program design, and what is easy to forget when using Turbo Vision is that your program is already designed. The event-driven architecture embodied in TApplication is complete and functional, and it will shape everything else your program does from top to bottom. Don't fight it. The thing was created to save you time, and if you persist in trying to twist it in some direction that aligns with your own biases, you'll be wasting huge amounts of time and energy.

Regardless of how willing you are to work on Turbo Vision's own terms, there remains the question of how to learn it. Turbo Vision is hard to learn in part because it's one big, heavily integrated mechanism and not a loose bin of software odds and ends. It's tough to pull one element of TV up for examination without having to understand seven hundred other things first.

This is what I call "looking for the front door;" it's the search for a starting point on a sequential path to mastery of the product.

There's no easy front door to learning TV, and that sequential path is inevitably going to be cluttered with forward references. As with anything else, you'll learn best by doing. Here's my suggested strategy:

1. Start by reading the Turbo Vision tutorials in Part 1 of the Turbo Vision Guide. Pull up the demonstration apps as you go, run them, and see if you can make any sense at all of the code. (This sort of experience is cumulative. Eventually the Aha! Insight! epiphanies will come so quickly your head will spin.) Much of it won't make sense, and a lot of what may seem to make sense at first won't stick. Don't worry -- and don't get discouraged. Just keep going.
2. Before you begin tinkering with TV itself, read up on and experiment with the TCollection class and its children. These stand independent of TV, and can be learned and used without any knowledge of TV.
3. Read the rest of TV Guide Part 2, which is a detailed description of Turbo Vision. The first time through, this will be rough going. Again, bull through it at least once, and twice if you have the intestinal fortitude.
4. Take one of the example apps and begin changing it, one thing at a time. Start small. Change the wording on a window title. Add a dummy menu item. Add a dummy command to the status line. Each time you make a change, crank your brain wide open to the place in the big picture where your one small change fits in. This is the stage where you have to try to pull all your previous undigested knowledge together. If you have the leisure, I'd suggest spending two or three full days doing nothing else; or failing that, a solid week of evenings.
5. Specify a simple application of your own, and try to make it happen. Steal freely from the example apps. They work well, and they were written by people who will probably always know more about TV than you will. Try to shape your learning app such that it can be added to incrementally, allowing you to test and learn from it as you go, in small chunks. Don't try to make 1500 lines of TV code compile at once, the first time.

Copyright © 1991, Dr. Dobb's Journal