Computer programs are often written in a high-level programming language, such as C#, Java, Visual Basic, Python, etc., and are then translated into a machine-executable program comprising machine-level instructions to be executed and/or low-level instructions to be interpreted. As part of the translation, the computer program may be transformed into an abstract semantic tree, which represents one or more operations and the parameters provided thereto as a hierarchical, node-based tree structure, wherein some nodes comprise the names of operations (such as methods to be invoked) or conditional logic statements, and wherein leaf nodes comprise parameters provided to such operations or conditional logic statements specified in the parent nodes. An abstract semantic tree serves to represent the meaningful information in the text of a program as a data structure, without the formalisms of special parts of the text that are required when a program is represented in text form. One advantage of such a syntax tree is that a development environment may permit a user to choose among a set of programming languages in order to write a computer program. The development environment may then build the application by parsing the programming language with a language-specific parser to construct an abstract semantic tree. The abstract semantic tree so produced may be further processed (e.g., compiled into a partially or wholly compiled executable binary, or prepared for interpretive execution) and coupled with precompiled programming libraries and other modules, and such processing may be performed consistently with less impact due to the programming language of the source code. In this manner, a computer program written in any programming language may be prepared for execution with the same programmatic logic and utilizing the same programming libraries, and resulting in the same executable program and attendant behavior, as operationally equivalent programs written in other programming languages.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Contemporary programming languages often include expressions for dynamic operations, where an operation invoked in different circumstances may proceed in wholly different manners. As one example, many object-oriented programming languages permit the declaration of polymorphic methods, comprising two or more methods having the same function name but different numbers and/or types of parameters (e.g.: “int Process(int iParam1, int iParam2)” vs. “int Process(string strParam1, string strParam2, string strParam3)”.) As another example, Perl permits functions to have side-effects, wherein a function invoked in a first instance may produce a different behavior than a function invoked in a second instance, in case an environmental parameter is differently configured (e.g., an environmental variable may be set to different values to specify that the method should operate in different ways.)
A dynamic operation is not ambiguous—i.e., during an invocation, the dynamic operation may be evaluated in view of the relevant circumstances, such as the parameters specified during the dynamic operation—but it may be difficult to determine the behaviors that the dynamic operation is likely to exhibit prior to runtime, due to the varied and potentially large number of behaviors that may be invoked based on different circumstances. Accordingly, during runtime, a full evaluation of the circumstances and the possible behaviors is often performed for a particular invocation of the dynamic operation. The complexity of this analysis may involve a significant consumption of computing resources if fully performed for successive invocations, e.g., if the same invocation is performed multiple times through a loop. Moreover, this consumption may be unnecessary and may comprise an inefficiency, e.g., if most or all invocations of the dynamic operation occur under circumstances leading to one particular result (such as repeated invocation of the dynamic operation with the same set of parameter types.)
One technique for mitigating this inefficiency involves storing some details of analyses performed for preceding invocations of the dynamic operation, and utilizing these prior analyses during a subsequent invocation by migrating the analysis toward the results of the preceding analyses. For example, if the analysis performed during a first invocation involved a series of tests that led to a particular conclusion and an a resulting action, then during a second analysis, the tests that affirmatively led to the former conclusion may be performed first. If these tests succeed, then the same conclusion may be reached more quickly during the second invocation, thereby avoiding unnecessary tests and improving the efficiency of the dynamic operation evaluation. Moreover, the evaluation may be devised as a method configured to perform the tests of the evaluation encoding the rules of the evaluation, which may be emitted as code by an evaluation builder function, and recompiled upon adjusting the evaluation to account for new rules.
To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.
The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the claimed subject matter.
Computer programs are written in one or more of the many programming languages that may be available for a particular platform, such as a particular computing architecture or operating system. The various programming languages may present different language features, such as functional vs. object-oriented programming or strictly vs. dynamically typed objects. However, the programmatic logic and flow expressed for a program written in a first programming language may be very similar to the programmatic flow and logic for a program written in a second programming language, unaffected by the syntactic differences between the first and second programming languages. Moreover, many programming languages may provide interfaces to a particular programming library (such as an application programming interface, or API) hosted by the operating system or another program, and the invocation of the programming library through a first programming language may be very similar to the invocation of the programming library through a second programming language.
Based on the significant fungibility of such programming languages, a software development environment (such as a visual software design tool) may support multiple programming languages, and may permit the developer to select among the multiple programming languages for developing an application. While building a program, the development environment may first standardize the program to an abstract, language-independent representation of the programmatic flow expressed in the program. The abstract representation may then be further prepared for execution (e.g., partially or wholly compiled into an executable binary, written as an interpretable program or script, and operatively coupled with programming libraries referenced by the program) without regard to the syntactic particularities of the selected programming language. The standardization of such programs early in the build process permits the application of a significant portion of the build pipeline to any program, and therefore reduces the necessity of building language-specific compilers and linkers. Moreover, by separating the programming language text representation particularities from the underlaying programming logic at an early build stage while retaining the semantic particularities, the development environment may promote consistency and standardization among versions of a program written in various programming languages.
One language-independent representation of the programmatic logic is an abstract semantic tree, comprising a logical structure organized as a tree and containing the components of the computer program in a hierarchical manner. Many nodes of the tree represent operations, such as method invocations and mathematical operations, and the children of such nodes may represent the parameters of the operation; e.g., “x=1+2” may comprise an “=” node with child nodes “x”, “1”, and “2”. Conditional logic may also be expressed as a set of nodes, with the operands of the condition test represented as child nodes; e.g., “if x, execute Method1; else, execute Method 2” may comprise an “if” node with a first child “x”, a second child “Method1”, and a third child “Method2”. Logic may also be nested; e.g., an “if” node may be a child node of another “if” node, and a “while” block may have a child node representing the while test and another child node representing the operations to be performed per iteration of the while test. A development environment may feature an abstract semantic tree generation component, and the build process for a program may involve generating an abstract semantic tree representation of the program at an early stage of the build process, upon which the remainder of the build process (compiling, linking, etc.) may operate. This process facilitates the building of an application in a standardized manner based on the underlaying programmatic logic, and without overly accounting for the syntactic constructs of the high-level programming language chosen by the developer to express the program logic.
One feature that may not be apparent at first glance from the example 10 of
The abstract semantic tree 18 of
Due to the ambiguity of the dynamic operation prior to the runtime invocation of the operation, processing such a dynamic operation node in an abstract semantic tree may be difficult, and the final interpretation of the dynamic operation may be deferred until the moment of invocation during runtime. Upon invocation of the dynamic operation, a runtime module that is hosting the compiled program, or an interpreter that is interpretively executing the program, may perform an analysis of the circumstances of the invocation (in this case, an assessment of the nature of the x parameter supplied to the “+” operator node 24) to determine the function or instructions to be invoked for the dynamic operation. However, the circumstances of the dynamic operation may change between two invocations—i.e., the x parameter may comprise an integer during a first invocation, but may comprise a string during a second invocation—so the runtime module or interpreter may have to perform the analysis again upon a second invocation of the dynamic operation.
The repeated analysis of the conditions under which a dynamic operation is invoked may impose a significant performance cost on the computing environment. For example, if the dynamic operation resides in a short but frequently iterated function, such as a short for loop invoked a thousand times, the repeated analysis of the parameters may significantly encumber the operation of the program and slow the computing environment. Moreover, such repeated analysis may be unnecessary if the circumstances do not change between invocations. For example, if Method1 is invoked with the same parameters during a short programming loop having many iterations, then the repeated analysis of the “+” operator node 24 may significantly diminish the performance of the program, despite reaching the same conclusion for each invocation of the Method1 method in the programming loop. However, it may be difficult to reduce this inefficiency prior to runtime, because it may be difficult to determine when the method might be invoked repeatedly with the same parameters and when it might be invoked with a different set of parameters, leading to a different analysis. As a result, languages that broadly support dynamic operations may incur a significant performance penalty due to the frequent and complicated analysis of such dynamic operations.
One technique for reducing the performance penalty involves storing the results of an analysis of a dynamic operation for use in the next iteration. For example, a dynamic operation invoked repeatedly in a particular location of a program is often invoked under the same circumstances and leads to the same resulting action. If the conditions giving rise to a result in an analysis of a first invocation of a dynamic operation can be stored, then upon a second invocation of the same dynamic operation, the computer system might directly test the same conditions, and may take the associated action if the conditions prove to be the same during the second invocation as during the first invocation. The analysis might therefore skip a significant part of the analysis that is unlikely to be relevant in light of the high probability of a similar invocation. This technique may therefore expedite the evaluation of the dynamic operation, without specifying or determining prior to the first runtime invocation how the dynamic operation might be used, and while preserving the dynamic aspect of the operation in case the circumstances of its invocation change.
This technique may be applied through the generation and use of an evaluation rule set associated with the dynamic operation.
The exemplary evaluation rule set 30 of
As illustrated by the exemplary evaluation rule set 30 of
Instead, upon identifying a satisfied rule (i.e., a rule in which the conditions of the rule are satisfied), the evaluation rule set may be updated to reflect the recent satisfaction of the rule, such as by increasing the priority of the satisfied rule within the series of rules to promote an earlier evaluation during the next invocation in case the same circumstances and analysis apply.
The techniques for evaluating a dynamic operation according to an evaluation rule set, such as illustrated in
It may be appreciated that the exemplary evaluation rule set utilized in
Instead of initiating the evaluation rule set for the dynamic operation during its first invocation, an evaluation rule set may be associated with the dynamic operation during the building of the application.
The techniques discussed herein may be implemented with variations in many aspects, wherein some variations may present additional advantages and/or reduce disadvantages with respect to other variations of these and other techniques. Such variations may be compatible with various embodiments of the techniques, such as the exemplary method 80 of executing a dynamic instruction illustrated in
A first aspect that may vary among implementations relates to the dynamic operation. The techniques for evaluating the dynamic operation according to an evaluation rule set may be applied to a dynamic operation included in an abstract semantic tree, and these structures may take many forms. As a first example, the program may simply be stored as uncompiled source code, such as a script. Upon invocation of the script, an interpreter may translate the program into an abstract semantic tree, which may be interpretively executed or partially or wholly compiled into low-level or machine instructions that can be directly executed. Upon encountering a dynamic operation in either the abstract semantic tree or the compiled executable at runtime, the computer system may associate the dynamic operation with an evaluation rule set, which may be populated with rules during successive invocations of the dynamic operation over the course of the program execution. As a second example, the program may be translated into an abstract semantic tree that is stored in an interpretable format, such as a serialized binary tree representation of the abstract semantic tree. An interpreter may then be invoked to interpretively execute the XML representation of the abstract semantic tree, and when the interpreter encounters the dynamic operation as a node of the abstract semantic tree, the interpreter may utilize an evaluation rule set to determine the proper execution of the dynamic operation at the moment of invocation during runtime. As a third example, the program may be translated into an abstract semantic tree that is wholly or partially compiled into machine instructions or a low-level language, which results in the generation of a compiled dynamic operation. The compiled dynamic operation may be associated with an evaluation rule set to be used in analyzing an invocation of the dynamic operation at runtime. Those of ordinary skill in the art may be able to utilize the techniques discussed herein in many scenarios involving the translation of a computer program to an abstract semantic tree having a dynamic operation and the subsequent execution of the computer program.
A second aspect that may vary among implementations relates to the structure and contents of the evaluation rule set associated with a dynamic operation. As a first example, the conditions of the rules may be specified in an abstract format that may be interpreted in evaluating the conditions of a rule (e.g., a rule comprising the string “param1<4”, which the computer system may parse during the dynamic operation evaluation in order to formulate a condition that may be applied to the parameters of the invocation.) A set of such rules may also be specified, and the rules may be connected in various manners, such as with Boolean logic (e.g., “(param1=int and param1<2) or (param1=float and param1<1.5)”) or a scoring system (e.g., “at least two of the following four conditions: . . . ”) Alternatively, the conditions of the rules may comprise a method associated with the dynamic operation and configured to test the invocation of the dynamic operation with the parameters according to the conditions of the rules of the evaluation rule set and to return the action of the satisfied rule. For instance, the rule may comprise a delegate pair, wherein the first delegate specifies a function accepting the parameters of the invocation and returns a Boolean value indicating whether or not the conditions were satisfied, and the second delegate specifies a function to be invoked as the action of the satisfied rule by which the dynamic operation is to be executed. Representing the conditions as a method may permit the rule to specify a broad and sophisticated set of conditions. The conditions may also be adjusted during runtime by emitting a new function comprising a revised method, and by referencing the method as the delegate for the conditions of the updated rule. Those of ordinary skill in the art may be able to devise many representations of the conditions of the rules of an evaluation rule set in accordance with the techniques discussed herein.
A second variation of the structure and contents of the evaluation rule set, which may be advantageous where the conditions and actions of the rules are embodied as delegates, relates to the languages used to specify such delegates and to manage the parameters provided in the invocation. Some development environments may not only support multiple programming languages, but may permit cross-language operations, such as adding an object of a first programming language and an object of a second programming language, or of applying an operation in a first language to an object of a second language. The dynamic operation may be applied in such mixed-language circumstances. This application may involve some cross-language translation, e.g., translating a 32-bit primitive integer used in a first language into a 64-bit primitive integer accepted as a parameter of an operation of a second language, but the details of these techniques may be applied without significant hindrance. For instance, where the conditions of the evaluation rule set are specified as methods, an evaluation rule set may comprise a first rule having at least one condition of a first language, and a second rule having at least one condition of a second language. The computer system may evaluate the conditions of either rule by executing the method through the corresponding language runtime for the condition method, and the evaluation results may be compared in a language-independent manner. Those of ordinary skill in the art may be able to devise many applications in mixed-language computer programs of the techniques discussed herein.
A third variation of the aspect relating to the structure and contents of the evaluation rule set relates to the manner of deriving the conditions and the action to be performed for a satisfied rule. As a first example, the conditions and associated actions of the rules may be predefined, such as those embodied in a default evaluation rule set that may be inserted into an evaluation rule set associated with a particular dynamic operation. As a second example, a user (such as a developer) may provide a user-defined rule, comprising a set of user-defined conditions (such as a method configured to test the conditions) and/or a user-defined action (such as a method referenced as the action delegate of the rule.) This example features a pluggable aspect of the evaluation rule set, wherein a developer may acknowledge the dynamic nature of a dynamic operation, and may provide one or more rules for evaluating an invocation of the dynamic operation based on the most likely circumstances in which the method may be invoked. For instance, a developer may specify that an add operation performed on two unspecified parameters is likely to be invoked as a string concatenate operation by providing a rule (to be evaluated first in the evaluation rule set) with conditions specifying that at least the first operand is a string, and a method delegated as the action of the rule comprising the instruction: “((string)param1).Concatenate(param1.ToString( ))”. Such a method may be explicitly declared by the user, or may be designated as an anonymous method, and inserted into the evaluation rule set as a first-class object according to a code-as-data methodology.
As a fourth example of the third variation of this aspect, one or more rules of the evaluation rule set may be based on a rule template, which may be formulated as a meta-rule to be applied to the circumstances of a particular dynamic operation. The specification of the rules according to a rule template may serve to apply a similar evaluation of similar dynamic operations, and may reduce some unnecessary duplication of rules.
Upon building the application, the computer system may interpret this attribute by applying the rule template 124 to the dynamic operation, and by inserting into the evaluation rule set one or more rules generated by the application of the template. In this context, generating the evaluation rule set may comprise inserting into the evaluation rule set one or more applied rules based on the rule template and the dynamic operation. Alternatively, the computer system may store the template rule in the evaluation rule set, and the evaluation rule set may comprise at least one rule specified according to a rule template. Upon applying the evaluation rule set to the dynamic operation (such as upon encountering an invocation at runtime), the rule template may be applied to the dynamic operation to generate rules that may be applied in the evaluation. This example may benefit by reducing the duplication of such rules among many evaluation rule sets; e.g., if a program involves fifty instances of “param1+param2” dynamic operations, it may be more efficient to store a reference to a rule template in the evaluation rule set associated with dynamic operation than the fully expanded set of rules. Thus, the use of templates may provide a space-saving aspect, albeit at the modest expense of applying the rule template to the dynamic operation during runtime. Those of ordinary skill in the art may be able to devise many ways of utilizing rule templates in specifying the rules of the evaluation rule set while implementing the techniques discussed herein.
A third aspect that may vary among implementations of these techniques relates to the manner of evaluating the evaluation rule set. As one example, the evaluation rule set may be initially provided as an empty evaluation rule set. For instance, an empty evaluation rule set object may be associated with the dynamic operation during building; or the dynamic operation may initially not be associated with an evaluation rule set (e.g., a null reference), but upon failing to retrieve a rule set associated with the dynamic operation during the first invocation, the dynamic operation may be associated with a new evaluation rule set. Alternatively, the evaluation rule set may be initially generated with some or all of the rules of the default evaluation rule set, which may be reconfigured for improved efficiency upon successive invocations of the dynamic operation. As a second alternative, the evaluation rule set may be populated by the user, such as a developer, with one or more rules specified at design time.
Another example of variations in the processing of the evaluation rule set relates to the order of evaluation of the rules. For instance, the evaluation rule set may comprise an unordered set of rules, and the computer system may apply the conditions of the rules of the evaluation rule set to the invocation of the dynamic operation with the parameters in parallel, or in an arbitrary order, to determine a satisfied rule. This evaluation ordering may suffice if the rules are mutually exclusive, i.e., if the conditions specifying one rule may only be satisfied if the other rules cannot be satisfied for a particular invocation. For example, the conditions of rules may all relate to an analysis of primitive types of the objects, which may exhibit mutual exclusivity when applied to invocations of dynamic operations written in a language with strong and invariant typing.
As a first alternative organization of the rules of the evaluation rule set, the rules may be organized in a series, and the conditions of the rules of the evaluation rule set to the invocation of the dynamic operation with the parameters may be applied in a serial rule evaluation. The first rule may be evaluated first, and if the conditions of the first rule are satisfied, the evaluation may end and the action associated with the first rule may be utilized to execute the dynamic operation. If the first rule is not satisfied, then the second rule may be next evaluated, and if the conditions of the second rule are satisfied, the evaluation may end and the action associated with the second rule may be utilized to execute the dynamic operation. If the second rule is also not satisfied, then the serial evaluation may continue through the remaining rules of the evaluation rule set. A serial evaluation may be advantageous for permitting a simple reconfiguration of the evaluation rule set for improved efficiency by moving a satisfied rule to the beginning (or near the beginning) of the series, thereby prompting an earlier evaluation of the satisfied rule during the next invocation of the dynamic operation.
As a second alternative organization of the rules of the evaluation rule set, the rules may be organized according to a conditional hierarchy, and the evaluation may involve applying the conditions of the rules of the evaluation rule set to the invocation of the dynamic operation with the parameters according to the conditional hierarchy of the evaluation rule set. This ordering may be additionally efficient providing a log(n) process of condition evaluation, such that a condition that is included in several rules and mutually excluded from several other rules (e.g., “param1 is some kind of numeric type”) may be evaluated once, and the rules contrary to the result of the evaluation may be excluded from the evaluation. The hierarchical ordering of the rules may also permit more sophisticated specification of the conditions of the evaluation rule set, which may first implement some general tests of the circumstances pertinent to the dynamic operation invocation before applying more specific conditions (e.g., “is parameter 1 a primitive type? if not, is parameter 1 a type of user interface control? If so, is parameter 1 a type of button?”) Those of ordinary skill in the art may be able to devise many such organizational schemas for the evaluation rule set while implementing the techniques discussed herein.
A fourth aspect that may vary among implementations of these techniques relates to the configuration of the default evaluation rule set. As one example, the default evaluation rule set may automatically reflect on the accessible methods having the name of the dynamic operation, may compare the parameters by type with the parameters of each such available method, and may select a method configured to accept the parameters provided with the invocation. Each considered method may comprise an action of a rule, with the conditions of accepting the number and types of parameters provided with the invocation. An identified method may then be represented as the action of a satisfied rule, which may be generated and inserted into the evaluation rule set associated with the dynamic operation. As another example, the default evaluation rule set may include rules requesting one or more of the objects provided as parameters to provide a suitable action for performing the dynamic operation. For instance, if a “+” dynamic operation is invoked with a first parameter comprising a string and a second parameter comprising some object type, the default evaluation rule set may instruct the computer system to inquire with the String class for an appropriate method of performing a “+” on a string with the second parameter. Alternatively or additionally, the default evaluation rule set may include rules requesting a runtime that is managing one or more of the parameters to provide a suitable action for performing the dynamic operation. For instance, if the string specified in the “+” dynamic operation is managed by a C# runtime, the default evaluation rule set may instruct the computer system to inquire of the C# runtime to delegate a method for performing the “+” dynamic operation on its parameter of type string with the second parameter. Those of ordinary skill in the art may be able to devise many such default evaluation rule sets while implementing the techniques discussed herein.
A fifth aspect that may vary among implementations of these techniques relates to the reconfiguration of the evaluation rule set upon identifying a satisfied rule. As a first variation, if the evaluation rule set is embodied as a compiled method, an updated method may be compiled (e.g., by reflection emit) that includes the satisfied rule, and may be associated with the dynamic operation. The satisfied rule may be newly generated, selected from the default evaluation rule set, relocated within the evaluation rule set (e.g., by moving the order of evaluation of the satisfied rule earlier in the evaluation method), etc. If the evaluation rule set is organized according to a conditional hierarchy, then the inserted rule may comprise the action of the satisfied rule along with all of the conditional rules satisfied while navigating the conditional hierarchy to reach the node of the satisfied rule. For instance, if a satisfied rule is organized in a conditional hierarchy featuring a first condition (condition: “is param1 a primitive type?” answer: true) and a second condition (condition: “is param1 a string?” answer: true), and if the satisfied rule comprises the condition “param1.length<4”, then the rule inserted into the evaluation rule set may comprise all three conditions (“param1 is a primitive type, and param1 is a string, and param1.length<4”) and the action associated with the satisfied rule.
As a second variation of the aspect involving the reconfiguration of the evaluation rule set, the rule set may be devised as a serially monomorphic evaluation rule set. In this variation, the evaluation rule set comprises only a small number of rules, such as one rule comprising the rule satisfied during the most recent invocation of the dynamic operation. If the rule is not satisfied during a subsequent invocation of the dynamic operation, then the default evaluation rule set may be consulted to identify a satisfied rule, and the dynamic operation may be associated with a new evaluation rule set comprising the satisfied rule as one of a few rules, or as the only rule of the evaluation rule set. This variation may be useful where a high degree of confidence exists that the dynamic operation is likely to be invoked repeatedly under circumstances satisfying a particular rule, such as with parameters of a particular type, and that rules that were useful in analyzing prior invocations may not be as useful for subsequent invocations. The restriction of the evaluation rule set to a single rule may therefore economize computing resources by maintaining small evaluation rule sets for various dynamic operations. If a previous rule that has been removed from the evaluation rule set is never later satisfied, then the evaluation rule set stays as a monomorphic evaluation rule set comprising only the newest, most recent rule found for the operation. Alternatively, if a dynamic operation is found to satisfy various rules in different invocations, then the monomorphic nature of the evaluation rule set may be discarded, and the evaluation rule set may be allowed to comprise multiple rules to handle the varying invocations of the dynamic operation.
As a third variation of the aspect involving the reconfiguration of the evaluation rule set, the conditions of the rules comprising the rule set may be compared during the reconfiguration to reduce redundant condition testing. If rules are frequently inserted into the evaluation rule set having multiple conditions, then a condition may be retested several times for a particular invocation of the dynamic operation while evaluating several rules. For instance, multiple rules may begin with the condition “param1 is not null,” and it may be inefficient to test this condition upon evaluating several of the rules. Instead, when an evaluation rule set organized as a conditional hierarchy is reconfigured, the computer system may attempt to detect whether a condition present in at least two rules. If so, the condition may be inserted in the evaluation rule set as a parent node of the at least two rules, and may be removed from each of the rules. Reconfiguring the evaluation rule set to group rules according to shared conditions may result in a sophisticated and efficient evaluation rule set that differentially evaluates the rules according to shared conditions.
As a fourth variation of the aspect involving the reconfiguration of the evaluation rule set, the rule set may be devised to eliminate rules that may no longer be satisfied for future invocations of the evaluation rule set. For instance, a computer program may feature an integer that is only incremented (i.e., neither decremented nor reset) during the execution of the program, such as a system uptime timer. A rule may comprise a condition that may be invoked if the integer is below a certain threshold value. If the integer ever exceeds the value, the condition of the rule cannot be satisfied during the continued execution of the program. In this instance, the computer system may determine that the rule can no longer be satisfied for subsequent evaluations of the dynamic operation, and the computer system may remove the rule from the evaluation rule set. This variation may be implemented (e.g.) as a mechanism by which a delegate comprising a method evaluation of a condition may request the cancellation of the rule, in case the method determines that the condition can no longer be satisfied. Those of ordinary skill in the art may devise many variations in the reconfiguration of the evaluation rule set upon identifying a satisfied rule while implementing the techniques discussed herein.
The variations of the aspects discussed herein may be mutually compatible, and several variations may be included in an embodiment to achieve numerous advantages and/or reductions in disadvantages with respect to other embodiments.
The exemplary method 130 of
Having retrieved an evaluation rule set associated with the dynamic operation, the exemplary method 130 involves applying 142 the conditions of the rules of the evaluation rule set to the invocation of the dynamic operation with the parameters according to the conditional hierarchy of the evaluation rule set. If, during the evaluation of the rules of the evaluation rule set, the exemplary method 130 detects a rule of the evaluation rule set that cannot be satisfied for subsequent evaluations of the dynamic operation, the exemplary method 130 branches at 144 and involves removing 146 the rule from the evaluation rule set.
The exemplary method 130 continues by attempting to identify a satisfied rule while applying 142 the conditions of the rules to the invocation of the dynamic operation. If the exemplary method 130 fails to identify a satisfied rule, then the exemplary method 130 branches at 148 and involves retrieving 150 a default evaluation rule set, which may comprise at least one of a rule associated with a parameter of the invocation of the dynamic operation, and a rule associated with a runtime managing a parameter of the invocation of the dynamic operation. The exemplary method 130 then involves applying 152 the conditions of the rules of the default evaluation rule set to the invocation of the dynamic operation with the parameters to identify a satisfied rule. If a satisfied rule is identified while applying 152 the rules of the default evaluation rule set, the exemplary method 130 branches at 154 and rejoins the method as if the satisfied rule were identified at 148. If the exemplary method 130 fails to identify a suitable rule in either the evaluation rule set or the default evaluation rule set, the exemplary method 130 involves producing 168 a satisfied rule having an action that raises an exception.
Once the exemplary method 130 succeeds in identifying a satisfied rule at 148 or 154, the exemplary method 130 proceeds by acting upon the satisfied rule and reconfiguring the evaluation rule set. First, the exemplary method 130 involves compiling 156 an updated evaluation rule set including the satisfied rule. If, during the compiling 156, the exemplary method 130 detects a condition present in at least two rules, the exemplary method 130 branches at 158 and involves removing 160 the condition from the at least two rules, and inserting 162 the condition as a parent node of the at least two rules in the conditional hierarchy of the updated evaluation rule set. The exemplary method 130 proceeds by associating 164 the updated evaluation rule set with the dynamic operation, executing 166 the action of the satisfied rule. Having achieved the execution of an action suitable for the invocation of the dynamic operation according to the conditions of the evaluation rule set, the exemplary method 130 achieves the performance of the dynamic operation while updating the evaluation rule set for improved evaluation, and so ends at 170. Many such embodiments featuring multiple variations in several aspects may be devised by those of ordinary skill in the art while practicing the techniques discussed herein.
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.
As used in this application, the terms “component,” “module,” “system”, “interface”, and the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it may be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
Moreover, the word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims may generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the disclosure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.”