Patent Application
20080040360
The illustrative embodiments will be better understood after reading the following detailed description with reference to the appended drawings, in which:
The inventive subject matter is described with specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, it is contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies.
As discussed in the above “Background” section, in object oriented programming, it is often necessary to define a choice object type that is a sum of two branch object types. As an illustration of this concept, an exemplary schema that includes a choice type and its corresponding branch types is shown in
When a schema such as schema 101 is bound to object types, it becomes necessary to define the object oriented choice type. As also discussed in the above “Background” section, existing techniques for defining a choice type include a number of limitations. For example, existing techniques may require an object type that serves as a branch type to be placed in a fixed class hierarchy at the time that the object type is defined. This means that, when defining such an object type, it is necessary to anticipate that the object type will eventually serve as a branch type. This also means that a particular object type can only serve as a branch type for a single corresponding choice type rather than for multiple choice types. This single corresponding choice type must also, naturally, be known at the time that the branch type is defined. Additionally, existing techniques may require that the branch types can only be reference object types and cannot be, for example, value object types. Furthermore, existing techniques may render the choice type as weakly-typed and not easily discoverable.
By contrast, the design pattern for choice types that will be described below enables discrimination among branch types in a type-safe and discoverable manner. Additionally, the design pattern enables object types that will eventually serve as branch types to be initially defined without placing them in a fixed class hierarchy. Hence, these object types can be initially defined without the need to anticipate that they will later be used as branch types. Furthermore, these object types can serve as branch types for multiple choice types, without the need to anticipate the names or compositions of the choice types when the branch object types are initially defined.
A flowchart representing an exemplary method for defining a choice type is shown in
At act 212, a choice type input is received. The choice type input defines the choice type. The choice type input also designates a plurality of object types as branches of the choice type. An exemplary choice type input for the Address object type is shown below:
The exemplary choice type input shown above is merely one possible impelementation for defining the type indexed sum relationship between the choice type and the designated branch types. Many other possible impelementations are contemplated in accordance with the design pattern described herein. As shown in the above example, the choice type is first defined as a class “Address.” The aggregation capability is then provided through private fields including “dadr” and “iadr.” The choice type input then provides two constructors for the two branch types that are implemented as “if” statements. Without loss of generality, it is assumed that non-null instances are to be passed to the constructors. In the final fragment of the choice type input, a programmatic observation of the branch is enabled that includes the method name “As” whose behavior is similar to the “as” cast operator in the C# programming language.
At act 214, the designated branch types are associated with the choice type in a type indexed sum relationship. This association enables various instances of the choice type to be committed to one of the branch types. For example, consider a first instance of “customer” schema 101 corresponding to the following data:
As shown, the first line of this example indicates that the first instance corresponds to a customer named “Mary Rogers.” The third and fourth lines of this example indicate that Mary Rogers has an international address rather than a domestic address. Accordingly, for the first instance of the “address” choice type corresponding to “Mary Rogers,” the “address” element will be committed to the “InternationalAddress” type.
As a second example, consider a second instance of “customer” schema 101 corresponding to the following data:
As shown, the first line of this example indicates that the second instance corresponds to a customer named “Jim Smith.” The third line of this example indicate that Jim Smith has a domestic address rather than an international address. Accordingly, for the second instance of the “address” choice type corresponding to “Jim Smith,” the “address” element will be committed to the “DomesticAddress” type.
Committing an instance of the choice type to one of the corresponding branch types may be referred to as “case discrimination.” A flowchart representing an exemplary method for performing case discrimination on an instance of a choice type is shown in
At act 312, a projection of the choice type instance to the current branch type is attempted. For example, at act 312, an attempt may be made to project Mary Rogers's address data to the “DomesticAddress” branch type. As should be appreciated, this attempt will fail for a number of reasons. In particular, while the “DomesticAddress” branch type does not include a country field, Mary Rogers's address instance includes a country field. Additionally, while the “DomesticAddress” branch type includes a five digit zip code field, Mary Rogers's address instance includes a six character postal code with both letters and numbers.
At act 314, it is determined whether the attempted projection is successful. If, as in the case of Mary Rogers and “DomesticAddress,” the attempt is not successful, then, at act 316, it is determined whether there are any remaining unexamined branch types assigned to the choice type. If there are no remaining unexamined branch types, then, at act, 320, the choice type instance is found to be invalid because it does not project to any of the designated branch types.
In the case of the “address” choice, however, there is a remaining unexamined branch type, which is the “InternationalAddress” branch type. Thus, at act 310, the current branch type is set to “InternationalAddress,” and the method is repeated. At act 312, an attempt may be made to project Mary Rogers's address data to the “InternationalAddress” branch type. As should be appreciated, this attempt will succeed. In particular, just like Mary Rogers's address, the “InternationalAddress” branch type includes a country field. Additionally, just like Mary Rogers's address, the “InternationalAddress” branch type includes a postal code field that may include both letters and numbers. Thus, at act 316, the first instance of the address type is committed to the “InternationalAddress” branch type.
Exemplary code for implementing the method of
Next, a nested conditional statement that covers the branches of the choice may be constructed:
The exemplary use of the “As” operator that returns a Boolean (as opposed to returning void) to express the success or failure of a cast allows for a uniform treatment of value and reference types. It also allows for commitment to a branch without actually providing a non-null reference.
To reduce the complexity and time required to define a choice type, it may be advantageous to define the choice type by way of a reusable generic abstraction. Thus, the generic abstraction need only be defined a single time, while any choice type that shares the same construction as the generic abstraction can be defined by simply referring back to the generic abstraction. An exemplary reusable generic choice type abstraction of arity two is shown below:
The exemplary reusable generic choice type abstraction shown above enables commitment to a branch type to be stored explicitly in an integer field for the branches' index: 1 or 2. Additionally, the above example enables branch commitment to occur at constructor time, with one constructor per branch type. Furthermore, the cast method returns a Boolean to encode success (true) vs. failure (false). The branch types used in this example can be any value type or reference type.
The exemplary reusable generic choice type abstraction is easily extendable to an arity that is greater than two. Another exemplary reusable generic choice type abstraction of arity three is shown below:
Reusable generic choice type abstraction of an arity that is greater than two may also, for example, be defined as a nested choice with arities two and “n−1.” Thus, choices of an arity that is greater than two can be reduced to binary choices. An exemplary alternative implementation of a reusable generic choice type abstraction of arity 2 using a single field of type “object” is shown below:
An instance of a choice type may only be committed to a single branch type at any one point in time. In some scenarios, a commitment to a branch type may be immutable, meaning that it is permanent and it cannot be changed. However, in other scenarios, such as, for example, programming contexts, it may be advantageous to allow for mutable commitments, meaning that an instance of the choice type can change which branch it is committed to. Mutable commitments may, for example, be enabled by adding additional code onto reusable generic choice type abstraction code such as that shown above. Exemplary mutable commitment code that may be added onto reusable generic choice type abstraction code for arity two is shown below:
By virtue of the generic class choice of any arity, choice types may be anonymous. This may be beneficial for certain kinds of mappings. However, it is possible to form a nominal choice type as a new class by employing inheritance whenever necessary. An example of a nominal choice type for addresses is shown below:
As shown above, the choice-type state and behavior such as the cast operation “As” is inherited from the choice generics. It is only necessary to rehash constructors for the new nominal type. Thus, the amount of code required to produce the nominal choice type is quite small and simple in comparison to the full choice type definition.
The cast operation of choices may enable casts to all possible branches to be systematically attempted. However, static typing may not be guarantee that all branches are covered. Thus, a completeness checking operation is provided to gurantee that all branches are covered. An exemplary completeness-checking operation will now be described. First, delegate types for the actions to be performed on the branches of a choice may be defined. The exemplary completeness checking operation honors two options. In the first option, the instance of the branch type is processed by a function that returns a value/reference of a type that is independent of the branch type. In the second option, the instance is processed instead by a void-typed function, which is therefore supposed to cause side effects. Exemplary code for these delegate types is shown below:
An exemplary completeness checking operation that may be extended onto choice generics of arity two is shown below:
In the “Accept” method as shown above, the enumeration of actions to be performed on the various branch types is position-oriented. The “Accept” method may also, however, be overloaded for all permutations of the branch types. Exemplary code including overloads of the “Accept” method for choice generics of arity 2 is shown below:
Although the design pattern has been described above with respect to type-indexed sums/co-products, by duality the design pattern may also be applied to type-indexed products (TIP's) or tuples. TIP's are constrained such that the component types of the product must be distinct. Exemplary code for defining a TIP of arity two is shown below:
The above code employes the concept of a Tuple <X,Y> and an overloaded “Project” method for all components types. The “Project” method attempts to unpack the tuple for each component type. The object-oriented type system takes care of the TIP property, meaning that a composition of a TIP type will be refused if the same type is listed several times as a component type.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
The computer 110 may operate in a networked or distributed environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Although the subject matter has been described in language specific to the structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features or acts described above are disclosed as example forms of implementing the claims.
