Browse Prior Art Database

Bitmasking as a mechanism to customize component behaviors.

IP.com Disclosure Number: IPCOM000016402D
Original Publication Date: 2002-Nov-07
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 39K

Publishing Venue

IBM

Abstract

When developing a software component library, there is a need to maintain API signatures between versions. Additionally, libraries are limited to a collection of classes and methods that have static behavior prescribed at design time. These restrictions and limitations present a challenge to both the developer and user of said library. Problems, such a serialization compatibility, and the rigidness of an API hinders additional functional enhancements by both the owner and user of said library. This article describes a technique for customizing object behavior through the use of bitmasks instead of API get/set methods. Computer engineers have used bitmasking as a technique to configure runtime properties of, for example, ethernet adapter. This article applies the same technique to a software component library. This article proposes the use of component bitmasking at 3 levels: At definition time, the developer of the component would define customizations of the component based on bit patterns instead of traditional get/set API.s. At design time, the developer of an application would select an appropriate pattern or pattern range of bits to customize the component. At run time, an application could sample the environment and further customize the component, again by the use of bit patterns. The standard technique used in developing a widget library is to design behaviors and then provide access to these behaviors through get/set methods. When this technique is employed, the user of the component library is "locked in" to whatever function is explicitly defined in the API. Using components that are customizable through bitmasks, however, enhanced capabilities can be made available without affecting existing API signatures. This allows object instances serialized from an early version of a library to be deserialized and used with a later version of the library which contains enhancements to the object definition. Using this technique, compile compatibility can also be preserved more easily across versions of the library.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Bitmasking as a mechanism to customize component behaviors.

    When developing a software component library, there is a need to maintain API signatures between versions. Additionally, libraries are limited to a collection of classes and methods that have static behavior prescribed at design time. These restrictions and limitations present a challenge to both the developer and user of said library. Problems, such a serialization compatibility, and the rigidness of an API hinders additional functional enhancements by both the owner and user of said library.

This article describes a technique for customizing object behavior through the use of bitmasks instead of API get/set methods. Computer engineers have used bitmasking as a technique to configure runtime properties of, for example, ethernet adapter. This article applies the same technique to a software component library.

This article proposes the use of component bitmasking at 3 levels: At definition time, the developer of the component would define customizations of the component based on bit patterns instead of traditional get/set API.s. At design time, the developer of an application would select an appropriate pattern or pattern range of bits to customize the component. At run time, an application could sample the environment and further customize the component, again by the use of bit patterns.

The standard technique used in developing a widget library is to design behaviors and then provide access to these behaviors through get/set methods. When this technique is employed, the user of the component library is "locked in" to whatever function is explicitly defined in the API. Using components that are customizable through bitmasks, however, enhanced capabilities can be made available without affecting existing API signatures. This allows object instances serialized from an early version of a library to be deserialized and used...