marco
cantu

Grokking properties

It's one thing to know about properties and another to genuinely own the concept and understand its usefulness.

You can't program in Delphi without using properties. They're everywhere. Open the Object Inspector, and you see a Properties tab. Go to the Delphi help file, and every component has its list of properties. Write code and there's a good chance you'll type property names. But are you sure you fully grasp how properties work? Do you appreciate their power? Do you use properties effectively? If you can answer those questions with a yes, then read no further. But I've discovered from e-mail, newsgroups, and conversations that few Delphi programmers can.

Encapsulation to the max

Object Pascal properties are an extension of the encapsulation model provided by classes in most object-oriented languages. Object-oriented purists argue that methods should be public while data fields should always be private, to which many programmers reply: "What about the extra code? It's boring to write and slows performance when you're simply reading or setting a value." 

The properties in Object Pascal are a powerful solution to this dilemma. You declare a public (or published) property and map it to a private field or an access method. If you're mapping directly to a field there is no extra code to write and no performance drawback over using a public field. However, the encapsulation rule is fully preserved: The user of the component doesn't need to know how the property is implemented and the component writer is free to change the implementation. In fact, even if you change the property mapping to use an access method, all you need to do is recompile the code.

The component writer can also change the storage structure for the property and the internal data type. Many properties don't even map to data fields. For example, one of the most common Delphi properties, Caption, is not saved by components as an internal string. Instead, it's sent to the corresponding Windows API function to change the window text. The reverse operation is executed when you retrieve the component's caption.

Delphi properties are different from the corresponding concepts in Java Beans and COM. In those component models, properties are always resolved by methods. The convention in Java is to use set and get methods with the property name. (Despite this and other differences, the Java Beans component model was inspired in many areas by the VCL.)

More than a language feature

Properties are not only part of the language, they're also supported in the Delphi IDE and runtime system.

In Delphi, properties are often used in conjunction with run-time type information. When you declare the properties as published, the compiler generates internal type information structures. These structures are used mainly by the visual support and streaming systems. You can directly access this information using the data structures and routines available in the TypInfo unit. 

Published properties define the persistent state of an object. Using the Object Inspector in the Delphi environment or your own tools, you can set the initial values for the properties of an object. These are later saved in a DFM file and then included in the executable file, ready to be reloaded when the object is created. To be more precise, the DFM file contains all the information required to create the components and restore them to their initial state.

I call this "persistent" to contrast with the runtime state of a component, which often includes extra dynamic data. Part of a component's startup state is determined at runtime by the program and operating system. An obvious example is the Handle of a windowed control, which is reassigned every time by the OS.

It's important to note that by streaming an object, Delphi doesn't save its internal structure and doesn't dump the object memory to disk. That would be useless because an object often contains references to internal objects and strings that use separate memory areas. Instead of saving the object data structure, the streaming system works by querying objects for the value of each property of their published interfaces. 

Delphi's streaming system is quite elaborate and provides for default property values, which are not saved, and  special streaming conditions (indicated by the stored keyword). It also handles other special cases, including extra non property-based values that a component can save by overriding the DefineProperties method.

But that's not all

Properties provide additional features. I mentioned the new dynamic property access function available in Delphi 5 in my last article. Another important trick is enhancing array properties, which are based on an index you indicate within square brackets. The index is often numeric but can also be based on other data types. The Table component uses a default property based on strings -- the names of the table's fields. An array property of a component can now be set as the default, which is a nice shortcut. You can omit the property name and apply the square brackets to the original component:

TableCountry ['Capital'] := "Rome"

instead of:

TableCountry.Cities ['Capital'] := "Rome"

This is a typing shortcut. I think it is also the closest thing to an overloaded operator in Object Pascal!

One last question

Is Ctrl-Shift-C a regular part of your keyboard repertoire? The answer provides much insight into your use of properties. The key combination invokes the Class Completion feature and makes property use a breeze. Whenever you are about to add a global variable, type the property keyword, press Ctrl-Shift-C, and you're in the property business. 

Properties are one of the key elements of Delphi's architecture and of its success. No other visual environment shares this powerful and flexible feature -- not even the one with more programmers.

Queries about lost property may be addressed to me.

Originally written for InPublishing LLC for publication by Inprise Corp. Copyright 1999 Inprise Corp.