2.7 Adding properties on the fly

Adding properties on the fly

Visual FoxPro 6.0 supports adding properties on the fly, which is quite straightforward. Every object has a method called .AddProperty() that supports two parameters: the name of the new property and the initial value, which is optional. The default value for the new property is .F. just as it is in the Class Designer. Here is an example of one way to add a new property to the Visual FoxPro _Screen object:

_Screen.AddObject("SomeText","Hello World!")

Before Visual FoxPro 6.0, there was no internal feature that allowed adding properties on the fly. However, a public domain library called AddProp.fll did just what .AddProperty() does now. Sometimes ADDPROP is still useful for example, whenever you want to add a property to an object created using the SCATTER command since these objects don't have the AddProperty() method. You can download AddProp.fll from the Developer's Download Files at www.hentzenwerke.com.

Should you, or shouldn't you?

There has been quite a discussion about whether or not you should add properties on the fly. Object purists argue that it is bad design to do so, and I have to grant them a point. On the other hand, there are some good reasons to add properties on the fly. Most of these are concerned with performance and ease of use.

Imagine you want to create a little component that resizes a form and changes the dimensions of each contained object. The component should be very generic and usable in every application without making any changes to the existing interface classes.

To resize interface objects, you would most likely need to remember the original object dimensions. You could store these values internally in your component, but it might be a difficult and confusing process. On top of that, you could waste valuable resources by keeping those values in memory once the object is already destroyed. Keeping track of objects that get destroyed is not trivial unless you redesign these objects, and that's exactly what you don't want to do. One way to do that would be to use an observer object that keeps track of objects, but this might turn out to be a major performance bottleneck. For this reason, you would most likely keep wasting memory by tracking values that are no longer valid.

The next big issue to deal with is to map the values to objects. You'd have to store the object path, which takes up a lot of resources. Also, object paths might not be unique if somebody reuses object references. Another way of doing this is to store object references, which isn't recommended, because you might end up with outstanding object references.

The easy way to resolve these problems is to add a property to each interface object that stores the original dimensions. These properties automatically go away when the object dies, and it's easy to find them because they are encapsulated in each object. So now, all that's left to do is to code the resize algorithm. But that should be trivial, right?

However, there are a couple of issues attached to adding these properties on the fly. Imagine another component that adds properties with the same name, or maybe the object already has those properties

I recommend using AddProperty() as sparsely as possible. Only use it in special cases like the example above. Don't consider using AddProperty() as long as you are in the design phase. The need for AddProperty() will arise soon enough. AddProperty() should be used only for implementation-specific reasons, and its use should never be an intentional design decision.