Abstract
Various technologies and techniques are disclosed for using contracts in dynamic languages. For example, a contract can be directly associated with an object. The contract can then be used to provide type safety for the object. As another example, contracts can be used with mix-ins. A declaration for a contract is provided with a mix-in. The contract is associated with a target object at runtime when applying the mix-in. Conditions can be assigned to mix-ins that must be met before the mix-in can be applied to the target object. At runtime, if the target object meets the one or more conditions, then the mix-in can be applied to the target object.
Claims
1. A method, comprising: receiving a method call to register a mix-in, the method call including as a parameter a set of base mix-ins from which the mix-in inherits; at runtime of a target object, before applying the mix-in to the target object, determining whether the target object meets at least one constraint contract that constrains objects to which the mix-in can be applied; if the target object meets the at least one constraint contract, at runtime, applying the mix-in to the target object; and if the target object does not meet the at least one constraint contract, at runtime, throwing an exception.
2. The method of claim 1, wherein the method call further includes as a parameter at least one of an interface implementation provided by the mix-in or a set of types the mix-in is able to extend.
3. The method of claim 1, further comprising: associating with the mix-in the at least one constraint contract that constrains objects to which the mix-in can be applied and that must be met by the target object before the mix-in can applied to the target object.
4. The method of claim 1, wherein the target object is an instance of a class.
5. The method of claim 1, wherein determining whether the target object meets the at least one constraint contract is performed using reflection.
6. The method of claim 1, wherein the at least one constraint contract defines a condition.
7. A memory having computer-executable instructions for causing a computer to perform steps comprising: receiving a method call to register a mix-in, the method call including as a parameter a set of base mix-ins from which the mix-in inherits; at runtime of a target object, before applying the mix-in to the target object, determining whether the target object meets at least one constraint contract that constrains objects to which the mix-in can be applied; if the target object meets the at least one constraint contract, at runtime, applying the mix-in to the target object; and if the target object does not meet the at least one constraint contract, at runtime, throwing an exception.
8. The memory of claim 7 having further computer-executable instructions for causing the computer to perform steps comprising: associating with the mix-in the at least one constraint contract that constrains objects to which the mix-in can be applied and that must be met by the target object before the mix-in can be applied to the target object.
9. The computer storage memory of claim 7, wherein the target object is an instance of a class.
10. The memory of claim 7, wherein determining whether target object meets the at least one constraint contract is performed using reflection.
11. The memory of claim 7, wherein the at least one constraint contract defines a condition.
12. A system for restricting the use of mix-ins based on meeting of conditions comprising: a computer comprising a processing unit coupled to a memory, the memory storing computer-executable instructions which, when executed, cause the processing unit to perform the steps of: receiving a method call to register a mix-in, the method call including as a parameter a set of base mix-ins from which the mix-in inherits; at runtime of a target object, before applying the mix-in to the target object, determining whether the target object meets at least one constraint contract that constrains objects to which the mix-in can be applied; if the target object meets the at least one constraint contract, at runtime, applying the mix-in to the target object; and if the target object does not meet the at least one constraint contract, at runtime, throwing an exception.
13. The system of claim 12, wherein the method call further includes as a parameter at least one of an interface implementation provided by the mix-in or a set of types the mix-in is able to extend.
14. The system of claim 12, the memory storing further computer-executable instructions, which, when executed, cause the processing unit to perform the step of: associating with the mix-in the at least one constraint contract that constrains objects to which the mix-in can be applied and that must be met by the target object before the mix-in can be applied to the target object.
15. The system of claim 12, wherein determining whether the target object meets the at least one constraint contract is performed using reflection.
16. The system of claim 12, wherein the at least one constraint contract defines a condition.
17. The system of claim 12, wherein the target object is an instance of a class.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) FIG. 1 is a diagrammatic view of a system of one implementation for directly associating contracts with objects.
(2) FIG. 2 is a diagrammatic view of a dynamic language scripting application of one implementation.
(3) FIG. 3 is a process flow diagram for one implementation illustrating the stages involved in allowing a user to directly associate contract(s) with obj ect(s) in a dynamic language.
(4) FIG. 4 is a diagrammatic view for one implementation illustrating in exemplary API's for declaring and/or using contracts directly with an object.
(5) FIG. 5 is a process flow diagram for one implementation illustrating the stages involved in associating mix-ins with contracts.
(6) FIG. 6 is a process flow diagram for one implementation illustrating the stages involved in restricting use of mix-ins based on contracts or other conditions.
(7) FIG. 7 is a diagrammatic view for one implementation illustrating exemplary API's for registering and/or using mix-ins with an object.
(8) FIG. 8 is a process flow diagram for one implementation that illustrates the stages involved in handling implementation collisions.
(9) FIG. 9 is a process flow diagram for one implementation that illustrates the stages involved in supporting mix-in inheritance.
(10) FIG. 10 is a diagrammatic view of a computer system of one implementation.
DETAILED DESCRIPTION
(11) The technologies and techniques herein may be described in the general context as an application that allows creation and/or execution of dynamic language script applications, but the technologies and techniques also serve other purposes in addition to these. In one implementation, one or more of the techniques described herein can be implemented as features within a dynamic programming language or framework such as MICROSOFT ASP.NET Ajax, JavaScript, or from any other type of program or service that allows for creation and/or execution of applications created in a dynamic language.
(12) As shown in the diagram 10 of FIG. 1, in one implementation, a contract or interface 14 can be directly associated 16 with an object 18 or an instance of an object using a dynamic language 12. The term directly associated and direct association as used herein means a direct relationship between the first and second entity without achieving the relationship indirectly through some other entity. In one implementation, by associating contracts directly with objects, type safety can be introduced to dynamic languages. As noted in the background section, the term type safety means determining whether the calling party meets the contract that is expected by the receiving party (the method or other member being called/accessed). One example of such a contract that the receiving party can verify is whether or not the calling party is passing parameters of the correct data type or not. In instances where type safety is violated, an exception can be thrown, or another suitable action can be taken, such as following another path in the program. In one implementation, a runtime environment that executes or otherwise analyzes the dynamic language script containing the direct association is typically the one that makes the type safety determination, but it could also be done separately from the runtime environment, such as during development of the script(s). As described in further detail in FIGS. 5-7, contracts can also be associated with mix-ins in a similar fashion to introduce type safety to mix-ins in dynamic language environments.
(13) Turning now to FIG. 2 with continued reference to FIG. 1, a dynamic language scripting application 200 operating on computing device 500 is illustrated. Dynamic language scripting application 200 is one of the application programs that reside on computing device 500 (of FIG. 10). However, it will be understood that dynamic language scripting application 200 can alternatively or additionally be embodied as computer-executable instructions on one or more computers and/or in different variations than shown on FIG. 1. For example, some portions of dynamic language scripting application 200 may be embodied in a software development environment on a developer machine, while other portions of dynamic language scripting application 200 may be embodied in a runtime environment (such as one or more web servers) that execute the software previously created on the developer machine. As another non-limiting example of how dynamic language scripting application 200 could operate differently than shown in FIG. 2, multiple development computers could be used and/or multiple runtime computers could be used. Numerous other variations are also possible.
(14) Alternatively or additionally, one or more parts of dynamic language scripting application 200 can be part of system memory 104, on other computers and/or applications 115, or other such variations as would occur to one in the computer software art.
(15) Dynamic language scripting application 200 includes program logic 204, which is responsible for carrying out some or all of the techniques described herein. Program logic 204 includes logic for accessing a dynamic language script that directly associates contract(s) with object(s) in a dynamic language 206 (as described below with respect to FIG. 3); logic for using the contract(s) at runtime to provide type safety for the object(s) 208 (as described below with respect to FIG. 3); logic for allowing mix-ins to be used with objects that implement functionality associated with assigned contract(s) and/or that meet other conditions 210 (as described below with respect to FIG. 6); logic for associating mix-ins with the contract(s) they implement, and the contract(s) to the target(s) when the mix-in is applied 212 (as described below with respect to FIG. 5); and other logic for operating the dynamic language scripting application 220.
(16) Turning now to FIGS. 3-9 with continued reference to FIGS. 1-2, the stages for implementing one or more implementations of dynamic language scripting application 200 are described in further detail. In some implementations, the processes of FIGS. 3-9 are at least partially implemented in the operating logic of computing device 500 (of FIG. 10). FIG. 3 illustrates one implementation of the stages involved in allowing a user to directly associate contract(s) with object(s) in a dynamic language. The process begins at start point 240 with receiving input from a user to directly associate a contract with an object (stage 242). At design time, the user (such as a software developer), can perform this direct association between the contract and the object by inserting source code into a dynamic language script to define the contract, and by inserting source code to map the contract to a particular object. The contract is used at runtime to provide type safety for the object (stage 244). In other words, the dynamic language script is accessed (read or otherwise accessed), and the contract is used to determine whether or not the calling method or member meets the requirements that are expected by the called method or member. When type safety violations are discovered, exceptions can be raised or other steps can be taken to handle the situation appropriately. The stages can be repeated as desired for other objects (stage 246). The process ends at end point 248. In the discussion of FIG. 4, some code examples and further discussion of how contracts can be associated directly with objects will be illustrated.
(17) Turning now to FIG. 4, exemplary API's are shown for declaring and/or using a contract with an object. An Object API 260 is shown along with a Type API 272. The object API 260 contains various methods, such as GetType 262, Addlnterface 264, Removelnterface 266, Getlnterfaces 268, and/or other methods 270 which are not described for the sake of simplicity. Let's look at each of these methods in further detail, along with some code examples to illustrate the concepts.
(18) As described previously, contracts or interfaces can be directly associated with objects. To allow for that scenario, it is necessary to have some API method or other way of adding a contract or interface declaration to any object. In one implementation (and using the API illustrated in FIG. 4), this can be accomplished using the Addlnterface method 264. Here is an example of what source code might look like using this method:
(19) Object.AddInterface(instance, interfaceType);
(20) After executing the line of code above, the object will contain a direct association with the interface contained as a parameter above. Similarly, in one implementation (and the example shown in FIG. 4), a RemoveInterface 266 method is provided to disassociate the contract from the object. However, this method is not strictly necessary in other implementations.
(21) The GetInterfaces method 268 is used in the exemplary API to allow for reflection. Reflection allows a program to inspect its own structure and functionality, which can be useful for various purposes. One common use for reflection is for programmatically generating documentation of a program. Another common use of reflection is to perform duck-typing as described in the background, such as to help ensure that a particular method uses the parameters in the way expected.
(22) A code example of how the GetInterfaces method 268 could be used is shown below:
(23) Object.GetInterfaces(instance)
(24) In one implementation, use of the Getlnterfaces method 268 such as illustrated above will get the interfaces that have been directly associated with the particular object. Alternatively or additionally, the Getlnterfaces method 268 may return other associations that are indirect through the object's type.
(25) Let's now turn to the Type API 272 shown in FIG. 4. Three methods are shown in the example, namely the IslmplementedBy method 274, IsInstanceOfType method 276, and other methods 278. In one implementation, existing reflection APIs that may already exist for a given dynamic language framework can be modified to enable some of the techniques described herein, such as to take into account not only class-based interfaces but also the new instance-based ones. In such an implementation, the methods shown in the Type API 272 can be modified to account for this new functionality. In another implementation, new methods can be added that separately query for reflection information that is now available given the ability to directly associate between contracts and objects.
(26) FIG. 5 illustrates one implementation of the stages involved in associating mix-ins with contracts. As described in the background section, a mix-in is one or more member implementations that can be added dynamically to a target object. A mix-in can contain methods that can be added in one operation to an object, such as with an equivalent to an include statement that refers to the mix-in a group of code. The process begins at start point 290 with receiving input from a user to add a contract declaration for an implemented contract to a mix-in at design time into the dynamic language script(s) (stage 292). An implemented contract is a contract that the mix-in implements and that will be dynamically added to the target. A constraint contract is optionally associated with the mix-in implementation itself for verification of the target object before the mix-in is applied (stage 294). A constraint contract is a contract that constrains what objects the mix-in can be applied to. At runtime, the dynamic language script is accessed (read or otherwise accessed) in order to run the program. The implemented contract is associated with the target object when applying the mix-in to the target object (stage 296). The target object gets later used in a context that requires the implemented contract (stage 297). The code in that context is distinct from the target object and the mix-in. Because the implemented contract was added when the mix-in was applied, the code in that context is able to verify that the target object satisfies the implemented contract, typically using reflection (stage 298), which is described in further detail in FIG. 6. The process ends at end point 300.
(27) Before jumping to FIG. 6, however, let's look at an example of how contracts can be used with mix-ins. Suppose you apply an EnumerableArrayEx mix-in like this:
(28) TABLE-US-00001 var a = [Zero, One, Two, Three, Four, Five, Six]; Object.mixin(a, Mixin.Collections.EnumerableArrayEx); if (Mixin.Collections.IEnumerable.isImplementedBy(a)) { var enumerator = a.getEnumerator( ); while (enumerator.moveNext( )) { write(enumerator.get_current( ), Item); } }
(29) In the example above, EnumerableArrayEx is a mixin that provides an implementation of IEnumerable. The EnumerableArrayEx is being added to an array. As soon as this is done, a implements the interface, even though its type (Array) doesn't. The interface can then be used with the certainty that checking for the contract provides. In other words, by associating the interface with the mix-in, type safety can be provided. The mix-in packages more information here than just implementation: it also packages the set of interface types that it implements.
(30) In the previous code example, the EnumerableArrayEx mix-in is assuming that its target is an array. Other mix-ins may use one or several interfaces that they expect on their target. In one implementation, the Object.mixin method is responsible for checking that those types are present on the target at runtime. This is described in further detail in FIG. 7. Let's turn now to FIG. 6 before getting back to that concept.
(31) FIG. 6 illustrates one implementation of the stages involved in restricting the use of mix-ins based on contracts or other conditions. The process begins at start point 310 with assigning a constraint contract and/or other condition(s) to a mix-in that must be met by a target object (stage 312). At runtime, the constraint contract and/or condition(s) are verified against the target object when attempting to apply the mix-in (stage 314). An example of another condition that could be used includes a condition evaluated based on the data contained in the object. If the target object satisfies the constraint contract and/or other condition(s) (decision point 316), then the mix-in is applied (stage 318). If the target object does not satisfy the constraint contract and/or other conditions (decision point 316), then an exception is thrown (stage 320), or another suitable action taken. While this process may seem short and simple, it is important to take a moment to emphasize exactly what just happened. By assigning a constraint contract and/or other condition(s) to a particular mix-in, the system was able to enforce type safety for that mix-in. In other words, the mix-in was not allowed to be used unless the object meets the requirements required by the constraint contract or other conditions. The process ends at end point 322.
(32) FIG. 7 illustrates one implementation of exemplary API's for registering and/or using mix-ins with an object. In the examples shown, there is an Object API 340 and a Type API 350. The Object API 340 includes a Mixin method 342 and other methods 344. The Mixin method 342 was described briefly in the discussion of FIG. 5. The Mixin method 342 is responsible for checking that the specified types are present on the target object at runtime.
(33) While not strictly necessary, in one implementation, a helper method is provided to declare mixins (RegisterMixin method 352), as well as additional reflection methods that apply to mix-ins (IsMixin 354 and Mixin 356). The RegisterMixin method 352 registers a mix-in, declares which interfaces it provides an implementation for, what types of instances it can extend, and a set of base mix-ins that it will inherit implementations from. In one implementation, all parameters but the type name are optional. A code example is shown below:
(34) TABLE-US-00002 Type.RegisterMixin( typeName, implementedInterfaces, extendedTypes, mixins)
(35) Let's now look at an example of a mix-in declaration (note that the actual implementation is not included):
(36) TABLE-US-00003 Mixin.Collections.CollectionArrayEx.registerMixin( Mixin.Collections.CollectionArrayEx, [Mixin.Collections.ICollection], [Array], [Mixin.Collections.EnumerableArrayEx]);
(37) In the example shown, the CollectionArrayEx mix-in implements ICollection (and any interface that the mix-ins it inherits from implement, in this case IEnumerable). The mix-in in this example applies only to Array instances and inherits from EnumerableArrayEx.
(38) The IsMixin method 354 is used to determine if a type is a mix-in. The method returns a true or a false value to indicate whether or not the specified type is a mix-in. Here is an example line of code for how that method could be used:
(39) Type.isMixin(type)
(40) To extend an object or all instances of a type with a mix-in, the Mixin method 342 (for the Object API 340) or the Mixin method 356 (for the Type API 350) can be used. Here is some example code for extending an object using the Mixin method 342.
(41) Object.mixin(target, mixin)
(42) Similarly, here is some example code for extending a type (or all instances of a type) using the Mixin method 356:
(43) Type.mixin(target, mixin)
(44) In one implementation, a RemoveMixin method 358 can also be provided in the Type API 350 to remove a mix-in from an object.
(45) FIG. 8 illustrates one implementation of the stages involved in handling implementation collisions. The process begins at start point 370 with checking for the existence of a method before it is being added to the mix-in (stage 372). If a method does not exist (decision point 374), then an exception is thrown so a bug can be caught earlier (stage 376), such as before attempting to make a method call to a method that does not exist. It is better to catch this type of problem before trying to actually call the method. Some or all of the technologies and techniques discussed herein now make such checks possible. The process ends at end point 378.
(46) FIG. 9 illustrates one implementation of the stages involved in supporting mix-in inheritance. The process begins at start point 400 with allowing a mix-in to be extended by other mix-ins (stage 402). A mix-in inherits interfaces and/or conditions packaged with any mix-in that it is being extended with (stage 404). Let's look at these two stages in further detail to help make them clearer. As described previously in the background section, one of the points of mix-ins is to enable developers to add functionality to objects as needed. There are cases where a library may want to give several different levels of granularity to the features and leave the choice to the developer on what to add. Suppose, for example, that CollectionArrayEx implements both ICollection and IEnumerable, but there is already an implementation of IEnumerable: EnumerableArrayEx. To avoid code duplication, it is possible for a mix-in to be extended by other mix-ins. Essentially, this amounts to mixing EnumerableArrayEx into CollectionArrayEx. The process ends at end point 406.
(47) As shown in FIG. 10, an exemplary computer system to use for implementing one or more parts of the system includes a computing device, such as computing device 500. In its most basic configuration, computing device 500 typically includes at least one processing unit 502 and memory 504. Depending on the exact configuration and type of computing device, memory 504 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. This most basic configuration is illustrated in FIG. 10 by dashed line 506.
(48) Additionally, device 500 may also have additional features/functionality. For example, device 500 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 10 by removable storage 508 and non-removable storage 510. Computer storage media includes 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. Memory 504, removable storage 508 and non-removable storage 510 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical 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 accessed by device 500. Any such computer storage media may be part of device 500.
(49) Computing device 500 includes one or more communication connections 514 that allow computing device 500 to communicate with other computers/applications 515. Device 500 may also have input device(s) 512 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 511 such as a display, speakers, printer, etc. may also be included. These devices are well known in the art and need not be discussed at length here. In one implementation, computing device 500 includes dynamic language scripting application 200 (described in FIG. 2 and other figures herein).
(50) Although the subject matter has been described in language specific to 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 and acts described above are disclosed as example forms of implementing the claims. All equivalents, changes, and modifications that come within the spirit of the implementations as described herein and/or by the following claims are desired to be protected.
(51) For example, a person of ordinary skill in the computer software art will recognize that the examples discussed herein could be organized differently on one or more computers to include fewer or additional options or features than as portrayed in the examples.
