Computer programs are groups of instructions that describe actions to be performed by a computer or other processor-based device. When a computer program is loaded and executed on computer hardware, the computer will behave in a predetermined manner by following the instructions of the computer program. Accordingly, the computer becomes a specialized machine that performs the tasks prescribed by the instructions.
A programmer utilizing a programming language creates the instructions comprising a computer program. Typically, source code is specified or edited by a programmer manually and/or with help of an integrated development environment (IDE). Subsequently, the source code can be compiled or otherwise transformed by another program into computer instructions executable by a computer or like device.
By way of example, a programmer may choose to implemented code utilizing an object-oriented programming language (e.g., C#, VB, Java . . . ). In accordance with such a paradigm, programmers will create a number of classes identifying properties and characteristics of an abstract thing as well as methods describing class behavior or abilities. Specific programmatic logic can then be specified as interactions between instances of classes or objects, among other things. Subsequently, executable code for a particular machine can be produced by an associated compiler. Alternatively, code can be transformed into intermediate code for a target virtual machine to facilitate execution on multiple computer platforms via further compilation or interpretation of the intermediate code.
For the most part, programs are written in a single programming language. However, in some instances, it is desirable to interface with code outside a native code environment. Foreign function interfaces (FFIs) are employed in these situations to enable functions of a foreign language to be called from a native language. In other words, FFIs (also referred to as language bindings or native interfaces) provide a mechanism for inter-language calls such that programs written in one programming language can call routines or make use of services in specified in another programming language. Examples of conventional FFIs include platform invoke (p/invoke) and Java Native Interface (JNI) which allow source languages to specify that certain methods be implemented as native platform calls.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the claimed subject matter. This summary is not an extensive overview. It is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
Briefly described, systems and methods are disclosed for interfacing with a foreign code environment from a native/host programming language. More specifically, a native program can interface with existing, foreign constructs and/or functionality. In furtherance thereof, identified foreign code constructs are transformed to match native code calling conventions and/or semantics.
In accordance with one aspect of the disclosure, foreign code can be specified utilizing an attribute or declarative tag external to a related native construct. In other words, the foreign function interface is non-obtrusive. In this manner, dual mode execution can be supported, namely in native code and foreign code.
According to another aspect of the disclosure, an attribute can omit an implementation. Subsequently, the implementation can be determined and produced automatically as a function of various factors such as knowledge of one or both of native and foreign language syntax and semantics. Further yet, the generated implementation can be optimized to facilitate expeditious and efficient execution.
In accordance with yet another aspect of the disclosure, foreign code specification or identification can be statically checked to limit introduction of programming bugs. In particular, syntactic and/or semantic analysis can be performed on an attribute and included foreign code as a function of foreign language syntax and semantics as well as native construct declaration, for example.
Still another aspect of the disclosure provides for programmatic assistance to aid specification of an attribute or foreign function interface. Knowledge of native and foreign language syntax/semantics as well as associated native language construct can be employed to make suggestions, auto-fill and/or identify errors, among other things.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
Systems and methods are provided hereinafter with respect to interaction amongst a native/host programming language and foreign/guest language. The host language can include a non-obtrusive attribute associated with a native programmatic construct that identifies information pertaining to a foreign code implementation of the construct. The attribute can be employed to translate and/or generate foreign code matching host language calling conventions and/or semantics. In one instance, the program can be considered to have dual modes such that a construct can be executed in the host language and/or a guest language. Further yet, code associated with the attribute can be analyzed to identify errors and intelligent feedback provided to facilitate specification of the attribute and code therein.
Various aspects of the subject disclosure are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the claimed subject matter.
Referring initially to
In accordance with one aspect, programming system 100 can correspond to a foreign function interface for browser script languages. Conventional FFIs such as platform invoke allows source languages to specify that certain methods be implemented as native platform calls, but platform invoke is limited to global methods. This is adequate when that native platform includes libraries (e.g., dynamically linked libraries (DLLs)) that expose global functions. However, where the source language is object-oriented and the underlying platform is also object-oriented, the system 100 can perform object-to-object mappings to take advantage of the platform.
One exemplary use case can be for compiling code to browser script. For instance, a source code program can be developed (e.g., C, C#, VB, Java . . . ) and compiled to an intermediate language (e.g., common intermediate language). Subsequently, the intermediate language code can be compiled or translated to browser script code. In this case, situations can exist where programmers wish to designate interaction with existing or native browser script code. Programmers can specify or otherwise identify such interactions in a specific host programming language. However, the host language and guest, browser script language can be quite different. For example, the host language can include much richer constructs (e.g., properties, events, delegates, constructors . . . ) than the guest language (e.g., functions). The system 100 can bridge such gaps by morphing browser script calling conventions and/or semantics to those of the host language. For instance, the system 100 can facilitate access to a host language property in C# or IL via a JavaScript function.
It is to be noted that the system 100 provides several advantages over other approaches. In particular, conventional foreign function interface systems provide an un-interpreted translation, wherein users are required to specify all foreign functionality explicitly and it is blindly translated. Here as will be described further infra, users are not required to specify everything explicitly thereby facilitating development. Moreover, the calling conventions and/or semantics of a host language and guest language are known such that intelligent decisions can be made to automatically match or bridge the two worlds.
Turning to
In accordance with one aspect, the program 200 can be executable in two different or dual modes. By way of example and not limitation, where the program code corresponds to IL the program can be run like any other IL program utilizing a particular virtual machine or runtime for execution. This facilitates testing and development processes, inter alia. Additionally, the program 200 can be executable as a browser script. Accordingly, the attribute component 210 can specify or initiate generation of guest, browser script code separate from a host language implementation. As a result, the attribute component 210 may need to be specified outside the corresponding construct component 220 in a non-obtrusive manner to enable dual mode execution to be supported.
A representative identifier component 110 is depicted in
The context component 320 can cooperate with the attribute locator component 310 and identify a programmatic context associated with a browser script segment. This is significant since browser script code can be generated and/or translated as a function of programmatic context, as will be described further infra. In one instance, context can be identified by the context component 320 by discovering a programmatic element or construct with which an attribute is associated and determining or inferring its functionality, among other things. By way of example and not limitation, context can correspond to types of members such as methods, properties, indexers, events and/or sub-categories thereof.
Referring to
The translation component 410 can interact with code generation component 420 to assist in translation. Script attributes need not be specified completely where the missing information is capable of being inferred. In these cases, the code generation component 420, alone or in conjunction with an internal or external inference component 422, can generate missing code. For example, a script attribute can be attached to method, property and/or event declarations omitting the implementation. During transformation, besides translating the declaration, the body of a method can be filled with browser script access code. In another case, where an existing foreign function is not explicitly identified by an attribute, the inference component 422 can infer the name of the function based on an associated construct function name and/or other information concerning native and foreign languages, and the function name can be inserted by the code generation component 420. In this and other manners, intelligent decisions can be made regarding how to bridge native and foreign code worlds.
The transformation component 120 further includes an optimization component 430 communicatively coupled to the code generation component 420. The optimization component 430 can include a number of mechanisms to optimize code generation as a function of the code alone or in conjunction with other context information, for example. As a result, generated code is optimized for execution based or predetermined rules or inferences that can be made about logic and/or resources employed.
What follows is a description of various exemplary scenarios to facilitate clarity and understanding with respect to various aspects of the claimed subject matter. The examples are described with respect to transforming an intermediate language code previously specified in C# to JavaScript. It is to be appreciated that the claimed subject matter is not to be limited to specifies provided with respect to the below examples. There are numerous other ways that claimed aspects can be practiced or employed all of which are to be deemed within the scope of the appended claims. Examples are now provided for transformation of static methods, instance methods, properties, constructors and events.
Browser script attributes and/or code can be associated with static methods. Static methods act at a class level rather than an instance level. Hence, a static method should not refer to a specific instance of a class. Static methods can be translated to JavaScript functions whose parameters (if any) are exactly those of the declared methods and whose implementation simply calls a user specified JavaScript function passing those parameters. Consider for example:
Here, the class “Document” includes a static method “Alert” with a single parameter “message” and a custom attribute delineated by square brackets (“[ . . . ]”) specifying that a JavaScript function “alert” should be called for a browser script implementation. This high-level code can be compiled by a standard language compiler to the following intermediate code:
In turn, the intermediate language code can be transformed utilizing aspects of the claimed subject matter to the following JavaScript function:
Here, the JavaScript function “Document$Alert$System$String$($a0)” is produced corresponding to the host language static method “Alert.” As specified by the attribute, the native “alert” function is called with a single parameter “$a0.” Further, In JavaScript, “void” functions or those without a return statement actually return “null” at runtime. Accordingly, transformations of native calls can be preceded with the keyword “return,” regardless of whether the call returns something that is meaningful.
In this example, the function name “alert” was explicitly provided by a user via the script attribute. However, this name is not strictly required. In accordance with an aspect of the claimed subject matter, the name can be omitted and subsequently inferred and generated as a function of the high-level language name “Alert” and/or knowledge of script functions, among other things.
It is to be noted that the preceding example identified the generated intermediate code associated with compilation of a high-level program. However, for purposes of further clarity and brevity, the remaining examples are presented without the intermediate code with an understanding that it can be an intermediate step.
Instance methods refer to specific instances of class and as such are slightly more complicated than static methods. In particular, a pointer to the instance (e.g., “this”) is implicit in some host languages. To match the implied calling convention of such a host language to JavaScript, an implicit instance reference can be made explicit. By way of example, consider the following code snippet and associated transformation:
In this case, a method “Append Child” is called on a DOM (Document Object Model) object. The attribute specifies that the “appendChild” native JavaScript function should be utilized. In the transformation, the JavaScript function includes an additional parameter representing the object on which the method is being called “$a0,” wherein “$a1” represents the original method parameter.
Here, the translated function utilizes dot notation—object dot(“.”) method. As an alternative, the translated function could simply provide the object as the first parameter, namely “append.Child($a0, $a1)” rather than in a dot notation. In one instance, this could be controlled by addition attribute parameter flag that distinguishes between a dot notation and first parameter transformation.
Static and instance properties can simply correspond to specially named methods. Accordingly, a similar mechanism can be employed to generate property signatures as was utilized for static and instance methods. However, it may be desirable for the implementation to access a JavaScript property or object field. In that case, the attribute can include a set “Property” field. By way of example consider the following code segment:
Both the “get” and “set” methods are provided here, but either alone would suffice. For the above input, the following can be generated:
Note that the logic associated with getting a value and setting a value is omitted in the attribute and automatically provided or encapsulated in the generated code.
The next example deals with constructors, which are programmatic elements that construct an object or class instance. Constructors require special care in both semantics and implementation such that objects constructed in the scripting language include features of host language objects. For example, a host language may support virtual methods on objects. More specifically, to support virtual methods and polymorphism objects can have a virtual table or v-table. Accordingly, when generating objects one or more mechanisms should be provided to equip externally created objects with the same features as internally created objects of a host language.
In one implementation, constructors decorated with a particular keyword (“BSImport”) can employ an object returned by a JavaScript function call as an instance or “this” reference for the lifetime of the object. This feature is particularly useful and unusual in programming language native interfaces. It allows developers to utilize code such as the following:
Furthermore, it is to be appreciated that a mechanism can be employed to correctly attach type information to a return value of a generated method.
Events can also require some extensive tranformation where the concept of an event is different in a host and guest language. Events are simply instances where something has occurred, such as mouse click. Most languages include a high-level concept of events where an object can expose signals and other objects can subscribe to and react to such signals. However, implementations can be different amongst a host and guest script language such that a direct mapping does not preserve host language semantics. For example, a host language can support registration of multiple handlers for a single event (e.g., via multicast delegates), whereas a guest language like JavaScript can support only a single handler per event. In a case of a button, the host language can support a list of actions, while JavaScript supports a single action, upon click detection. Accordingly, a host language multicast approach may need to be mapped or implemented on top of a single cast events of a guest language.
By way of example, consider the following code fragment:
The developer interface, as expected by now, consists of adding a “JSImport” attribute and specifying a JavaScript event to which to bind. Because events in JavaScript are simply properties, the “Property” field of the attribute can be used. The above code can be transformed to the following script code leveraging the fact that JavaScript allows overriding of function pointers:
“System$Delegate$Combine$System$Delegate$System$Delegate$” and “System$Delegate$Remove$System$Delegate$System$Delegate$” are part of a multicast delegate implementation. They return delegates that contain the concatenation and difference between two delegate invocation lists, respectively. For instance, the first time a delegate is assigned to an event a function is created and the event is assigned to a function that involves the delegate. The delegate can then go through the handler list and dispatach events to each handler. Notice that because multicast delegates handle invocation lists internally, the delegate type's “Invoke” method need only be called once. In addition, because the translation generates “pure” JavaScript, independent of browser object model, any browser differences can be avoided at the compiler level.
It is to be noted that the claimed subject matter is not limited to class members such as functions and methods. The disclosed innovated aspects are also applicable to other programmatic constructs or elements such as objects or classes themselves. Accordingly, an attribute or declarative tag can be present on a class or type to facilitate transformation of a guest language object or intrinsic type (e.g., string, number, date/time, regular expressions . . . ) to a host language version thereof. Where the guest language is JavaScript or like scripting language, a prototype mechanism can be employed to set extra fields in an object that can be created. For example, a “string.prototype=myfunction( . . . )” assigns a new function to the intrinsic type string.
Turning attention to
It should further be appreciated that the analysis component 510 can also consider attribute context information provided by the identifier component 110, for example, to facilitate checking shorthand code. As previously described, attribute requirements can be allowed to vary where required information can be inferred from context. Accordingly, the analysis component 510 can include inference mechanisms or components such that errors can be generated where required information cannot be determined.
Historically conventional foreign function interface systems have been a source of bugs and runtime errors since compilers treat such information as opaque strings. The system 100 can prevent these errors by performing static checking. More specifically, attribute code can be analyzed syntactically and/or semantically to determine if the right number of arguments are provided and/or that the function being hooked into is correct, among other things. This is valuable in preventing runtime errors from occurring. However, there can be situations where a user may want an attribute and/or code therein treated as an opaque string. In such a scenario, the attribute can indicate via a parameter or other mechanism that code analysis should be turned off.
The aforementioned systems, architectures and the like have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components could also be implemented as components communicatively coupled to other components rather than included within parent components. Further yet, one or more components and/or sub-components may be combined into a single component to provide aggregate functionality. Communication between systems, components and/or sub-components can be accomplished in accordance with either a push and/or pull model. The components may also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.
Furthermore, as will be appreciated, various portions of the disclosed systems and methods may include or consist of artificial intelligence, machine learning, or knowledge or rule based components, sub-components, processes, means, methodologies, or mechanisms (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, classifiers . . . ). Such components, inter alia, can automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent. By way of example and not limitation, transformation component 120 can employ such mechanisms to facilitate translation and/or generation of foreign language code (e.g., browser script) matching calling convention and/or semantics of a host language code (e.g., IL, CIL . . . ).
In view of the exemplary systems described sura, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts of
Referring to
Referring to
It is to be appreciated that the subject systems, methods and the like are not limited to browser script code. They are appropriate or applicable for interfacing with any foreign code. The specific references to browser script or more specific JavaScript® are merely one particular implementation utilized to clarify and simply explanation of more broadly applicable concepts.
As used herein, the terms “component,” “system” and the like are 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 instance, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer 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.
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. Furthermore, examples are provided solely for purposes of clarity and understanding and are not meant to limit the subject innovation or relevant portion thereof in any manner. It is to be appreciated that a myriad of additional or alternate examples could have been presented, but have been omitted for purposes of brevity.
As used herein, the term “inference” or “infer” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines . . . ) can be employed in connection with performing automatic and/or inferred action in connection with the subject innovation.
Furthermore, all or portions of the subject innovation 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 innovation. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device 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 should 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.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system memory 1116 includes volatile and nonvolatile memory. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1112, such as during start-up, is stored in nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM). Volatile memory includes random access memory (RAM), which can act as external cache memory to facilitate processing.
Computer 1112 also includes removable/non-removable, volatile/non-volatile computer storage media.
The computer 1112 also includes one or more interface components 1126 that are communicatively coupled to the bus 1118 and facilitate interaction with the computer 1112. By way of example, the interface component 1126 can be a port (e.g., serial, parallel, PCMCIA, USB, FireWire . . . ) or an interface card (e.g., sound, video, network . . . ) or the like. The interface component 1126 can receive input and provide output (wired or wirelessly). For instance, input can be received from devices including but not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, camera, other computer and the like. Output can also be supplied by the computer 1112 to output device(s) via interface component 1126. Output devices can include displays (e.g., CRT, LCD, plasma . . . ), speakers, printers and other computers, among other things.
The system 1200 includes a communication framework 1250 that can be employed to facilitate communications between the client(s) 1210 and the server(s) 1230. The client(s) 1210 are operatively connected to one or more client data store(s) 1260 that can be employed to store information local to the client(s) 1210. Similarly, the server(s) 1230 are operatively connected to one or more server data store(s) 1240 that can be employed to store information local to the servers 1230.
By way of example and not limitation, code including script attributes can be developed, compiled into intermediate language code and transformed to browser script on either or both of client(s) 1210 and server(s)1230. Subsequently, browser script can be distributed by server(s) 1230 to client(s) 1210 via the communication framework 1250 for execution by associated browsers. In accordance with one aspect, this can enable new applications to be developed utilizing powerful programming languages (e.g., C#, Java, VB . . . ) and transformed into browser executable code to afford computer platform independence, among other things.
What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the disclosed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the terms “includes,” “has” or “having” or variations in form 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” as “comprising” is interpreted when employed as a transitional word in a claim.