Today, most applications are written using objects. These objects may be supplied by third parties or may be developed specifically for an application. By using objects, code may be easily reused and incorporated into many different applications without modification. In addition, if modifications are necessary, a new object may be created that inherits the functionality of the object. Then, new specific functionality may be added to the new object as needed. This ability to reuse and modify existing objects reduces the development time for new applications, sometimes as much as from months to weeks.
However, even though the use of objects has become very commonplace and is beneficial, the current approach for handling properties in these objects has several drawbacks. For example, if a first property in an object is dependent on a second property in another object, a developer must write code that monitors (i.e., listens) to the second property and, upon change, change the first property. One simplified portion of code that performs these functions is as follows:
void Button1_OnPressedChanged(bool NewValue){   if (newValue == true){   BackgroundColor = Color.Red;}else{   BackgroundColor = Color.Grey;}).
As shown, this callback function returns a value for the second property (i.e., BackgroundColor), whenever the first property (e.g., Button1 Pressed) changes. Therefore, each time the first property state changes, a value (e.g., Red or Grey) is computed and stored in the second property during the callback. This technique requires storage in the object for the second property. The storage is used to keep a current state for the second property.
Because developers may develop these objects in isolation, circularities between some of the properties within different objects may occur. For example, continuing with the above example, a callback function for the backgroundColor property may be added that changes the state of the Button1 Pressed property. While having a callback function that changes the state of a button pressed property due to a change in backgroundColor is not very realistic and would not typically occur in an application, it helps illustrate the problem that occurs when two properties change each other's state. In actual applications, typically, two parameter would not change each other's state directly, but other dependent properties would cause the circularity illustrated by this simplistic example. Therefore, given the example above, at runtime, once one of these two properties changes state, both will continue to change states indefinitely. This circularity problem must then be identified and corrected before proper operation can occur. Unfortunately, it is very difficult to test every combination of property changes. Therefore, some of these circularity problems may not surface until after a software product has been released.
Due to at least these limitations, the current model for handling properties of objects is not ideal.
USPTO Backgrounds
USPTO Backgrounds