REALbasic University Resources: RBU: Glossary Defines common REALbasic programming terms   Archives Previously published columns Translations: Dutch Courtesy of Floris van Sandwijk   Japanese Courtesy of Kazuo Ishizuka   Chinese Courtesy of Dong Li   RBU Translation Guide Information on Translating RBU into other languages Books: Matt's Book (2nd Edition!) Ideal for experienced programmers   Erick's Book Best for beginning programmers Websites: Mother Ship The publisher of REALbasic   RB Webring Links to hundreds of REALbasic websites   RESExcellence Another REALbasic programming column   REALbasic Developer Magazine The premiere source for REALbasic instruction. REALbasic University is Sponsored by Make your Mac do what YOU want it to. Create games, utilities, cool Mac OS X tricks. Download REALbasic now and create your own software.

REALbasic University: Column 079

OOP University: Part Three

First, let me apologize for the lack of lessons lately: I got swamped with stuff that had to be done before the holidays, and once I was on holiday myself, it was difficult to get back in gear and publish RBU. Therefore I'm going to publish two lessons this week!

In our last lesson we learned event-driven programming and what a change that was from traditional modal programming. That led us to the introduction of objects. But what are objects?

Introducing Objects

The concept of objects is both simple and complicated. It's simple because objects are familiar to us: we use dozens of objects every day. Everything around us in the physical world is an object: a pen, a table, a house, a cat, a person, etc. The concept of objects becomes complicated when try to extend that analogy into abstract computer programming. How can a cat become a computer object?

First, let's examine real-world objects. Instead of just understanding them instinctively, the way we learn as a child (when you give a child a teddy bear, do you explain to them it's an object?), let's look at them from a scientific point of view.

A scientist (or philosopher) would begin by classifying the object. There are different kinds of objects, some are similar, some are different. For instance, you could quickly divide all objects into two categories: animate and inanimate (living and non-living). A book is inanimate. A cat is alive.

Once we've figured out into which major category an item belongs, we could categorize it further. For instance, we could say the cat is a mammal, has claws, and four legs. Not all the values are either-or: we could define some characteristics numerically. As part of a cat's definition we could say it weighs within a certain range (.1 to 20 pounds), has a color, and even belongs to a species (Siamese, Manx, etc.).

Note that what we've done here is establish the general features of a cat. We can safely say that all cats will have these features. If an object doesn't, we can assume it's not a cat. However, keep in mind that we can't prove the opposite: just because an object has cat's characteristics doesn't mean it's a cat (a dog would fit the above characteristics just as well as a cat).

Once we've got our general cat characteristics down, we could further subset those to include specifics of a particular cat. For instance, one of my cats is named Mischief, is black and white in color, weighs eleven pounds, and is nervous and very sensitive.

We could break this down with as much detail as we wanted. For example, we could include a "personality" subset and within that specify things like "independent," "nervous," "sensitive," "curious," and "freakishly playful." Then we'd be able to compare the personalities of two cats and see if they were compatible.

What we've done is define the properties of a cat. We've created a general cat category (sorry for the unintentional pun there) and a subset of that is the specific cat Mischief.

Guess what? What we've just done is use the OOP concept of inheritance!

Think about it. To a computer, an object is just a structure. A structure consists of a list of properties (characteristics). We could call that general cat object catObjectClass, which is a subset of a animateObjectClass object, which in turn is a subset of the objectClass object (remember, we started with an object, divided that into living and non-living, and created a cat subset of that). If we outlined this as a tree, here's what we'd have:

Note that when we subset a class of object, what we're doing is creating a new class of object that has all of the parent's characteristics (it inherits all the parent's properties). That's why catObjectClass inherits the "alive" property from animateObjectClass and why cats Mischief and Mayhem inherit the properties of catObjectClass.

Here's where inheritance can become confusing. It's not too difficult to understand that cats Mischief and Mayhem inherit the "color" property from catObjectClass: but remember, they don't necessarily inherit the value of that property. That's a key distinction. catObjectClass contains the property "color" but it's not defined except within Mischief and Mayhem.

Mischief and Mayhem can also override a existing property. If, sadly, Mayhem were to be run over by a UPS truck, his "alive" property could be set to false.

It is critical you understand this, because as objects become more complicated, it's easy to confuse properties with their values. That's because as humans, objects are so natural that we don't usually think of characteristics as a property, but as the characteristic itself. When we see a black cat we think "There's a black cat," not "There's cat object with a color property of black." After a while, "black" seems like the property, and it's not. The property is color. Black is the value. Computers don't think like people and they are very precise when it comes to distinctions like this.

It's also important to understand that subclasses can add properties. That's how catObjectClass adds things like "color" and "species." A subclass cannot delete a property inherited from its parent, but it can redefine it (change what it means). For example, objectClass can define "alive" as a boolean (true/false) data type. But catObjectClass could redefine "alive" as a double (though that's not necessarily a good idea). But catObjectClass cannot delete the "alive" property it inherits no more than you can delete the baldness gene your grandfather passed down to you (though you could take an anti-balding drug and try to change what that gene means).

Next Week

The concept of objects is elaborated with a discussion on the naming of objects.

Letters

This week Dave writes with a question about using Command-Shift-Period to stop a running program:

I saw reference to this in an old RBU article regarding RB 2.1. Is there anything similar to break out of an endless loop in RB 4.5 without stopping RB itself?

Dave

Command-Shift-Period doesn't seem to work in 4.5, and though force quitting an app under Mac OS X doesn't hurt anything, it is annoying. A better solution is to insert your own emergency exit routine. There are a couple ways to do this.

One is to put a check for userCancelled within the loop. That will allow the user (you) to press Command-Period to stop the endless loop.

  
  if userCancelled then 
    exit 
  end if 
   

Another solution I sometimes use is to increment a counter variable and if the count gets too high (set the amount to an absurdly high number), assume we're in an endless loop and exit:

  
  count = 0 
  do 
    // loop's code is here 
    ... 
   
    // Emergency exit 
    count = count + 1 
    if count > 100000 then 
      exit 
    end if 
   
  loop until done 
   

Note that this just exits the loop: it does nothing to solve whatever caused the endless loop.

Remember, you should only need to do this kind of thing during your debugging and testing phase: your final program should be written so it's impossible to have any endless loops in it!

Each week we answer select reader questions, and we're always open to ideas for future columns. Send your questions to . (Keep your questions simple and specific. General queries like "How do I write my own web browser?" will be neglected.) Your question won't be answered immediately, but will be answered in a future column. (If you don't want your correspondence published, just be sure to indicate that when you write. Otherwise it's fair game.)

About the Author
is an author, philosopher, graphic designer, photographer, film director, soccer fanatic, and programmer (among other things). He writes for MacOpinion, runs his own software company, Stone Table Software, which sells the revolutionary Z-Write word processor, and is Publisher and Editor of REALbasic Developer. He lives in Northern California with his cats, Mischief and Mayhem, and is rapidly running out of free time.

See the REALbasic University Archives

.