|Publication number||US8065668 B2|
|Application number||US 10/848,402|
|Publication date||Nov 22, 2011|
|Filing date||May 17, 2004|
|Priority date||Jul 10, 2000|
|Also published as||EP1174791A2, EP1174791A3, US20040216094, US20120072890, US20160124726|
|Publication number||10848402, 848402, US 8065668 B2, US 8065668B2, US-B2-8065668, US8065668 B2, US8065668B2|
|Inventors||George H. Bosworth, Patrick H. Dussud, James S. Miller, Daryl B. Olander|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (36), Non-Patent Citations (82), Referenced by (14), Classifications (8), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of and claims the benefit of U.S. patent application Ser. No. 09/614,158, now U.S. Pat. No. 6,738,968, entitled UNIFIED DATA TYPE SYSTEM AND METHOD and filed on Jul. 11, 2000, and which is a continuation-in-part of U.S. patent application Ser. No. 09/613,289, entitled UNIFIED DATA TYPE SYSTEM AND METHOD and filed on Jul. 10, 2000, now abandoned, both of which are incorporated herein by reference.
The present invention relates to a system and method for defining and processing data types and more particularly relates to type systems used by a compiler and/or runtime environment.
Almost from the beginning, computer programming languages have embodied the notion of data types. Data types include such basic concepts as a character, string, integer, float, and so forth. At its lowest level, data stored in a computer is a simple bit pattern stored in a location of a particular size (e.g., a 32-bit memory location). Data types define the notion of how to interpret the bit pattern. For example, a particular bit pattern in a storage location of a particular size might be interpreted one way if the storage location was deemed to hold a “character” and another way if the storage location was deemed to hold an “integer”.
In some computer languages, although the notion of data type exists, few rules are enforced either by the compiler or any associated runtime for mixing of different data types in expressions of a computer program. So no compiler error will be generated in the C programming language, for example, if an integer value is multiplied by a floating point number value. In order to minimize various types of errors, many such languages had built-in type rules that allowed for the implicit conversion of certain data types. In other instances, languages included explicit constructs to “coerce” or convert one data type into another data type. Needless to say, although such languages provided great flexibility, certain programming errors could be introduced if care was not taken when mixing data types in various programming expressions.
Strongly typed languages tried to reduce the instances of programming errors by enforcing strict typing rules. In strongly typed languages, a compiler error would be generated when data type mismatches were detected. For example, a compiler error would be generated in Pascal if a programmer tried to assign a character value to an integer variable. This had the effect of reducing certain types of programming errors, but the rules seemed to be too restrictive.
With the advent of object oriented programming languages, the concept of data types took on new meaning. In object oriented languages, objects may typically be represented by an object class hierarchy, where some objects are derived from (or inherit) fields (also referred to as properties) and methods from other “base class” objects. Objects in these languages can be a mixture of fields (typically represented by variables of a particular data types) and methods or functions which allow manipulation of the fields or which provide certain functionality. In addition, object oriented languages also typically include a number of built-in data types, such as float, integer, character, string and so forth, which can be used either as basic variables or as fields in an object. Thus, in Java, for example, a programmer can define a variable of type integer and define an object with fields, one of which is of the “integer” data type.
In object oriented programming languages, there can be different treatment for objects and basic data types. For example, an object with a single property of type integer and a variable of type integer would not be considered to be of the same data type in many object oriented languages, although at the bottom, both simply represent an integer. The variable of type integer simply exists as a bit pattern in a particular storage location with no additional information, while the object has a storage location of the same size and additional information (or “metadata”) that describes how to interpret the value in the storage location.
To provide some sort of equivalency between an object representation and a basic data type representation, the notion of “boxing” was conceived. The process of adding metadata to a basic data type representation to yield an object representation is termed “being”. Similarly, removing the metadata from an object representation to yield a basic data type representation is termed “unboxing”. However, even with the development of boxing and unboxing, present compilers and/or runtime systems use a fragmented notion of data types with strict separation between the notion of objects and the notion of basic data type representations. Although this separation has many implications, one area where the implications are quite apparent is in how these languages treat user-defined types.
Even prior to object oriented programming, many, if not most, programming languages had the notion of user-defined data types. These programming languages allowed a programmer to build up new “data types” from the basic built-in types of the language. For example, a programmer could define a new type “data_point” as consisting of an x coordinate value of type float and a y coordinate value of type float. Certain object oriented programming languages, like Java, however, do not allow extension of the basic built-in types in this manner. In some such implementations, user-defined types are only allowed in the form of objects. Existing solutions have also failed to adequately address the need for a unified data type system that can be applied during runtime.
The present invention addresses, among other things, a mechanism to avoid the currently fragmented view of data types. The invention also addresses the inefficiencies associated with using basic data types where object types would be more efficient and object types where basic data types would be more efficient.
In accordance with the present invention, the above and other problems are solved by providing a system and method for efficiently processing user-defined data types. The present invention provides for a more unified view of the type system of programming languages, and object oriented programming languages in particular. In the present invention, the type system includes a dual representation for basic data types. One representation is the basic data type representation common to such basic built-in data types. In this application this representation will be referred to as a value type representation, or more simply, a value type. However, unlike other type systems, each of the basic data types also has a boxed representation that exists in the object hierarchy of the type system itself. This dual representation can also be extended to user-defined types, so that user-defined types may exist both as a value type and as an object within the object hierarchy of the type system. This allows the compiler and/or runtime to select the most effective and efficient representation for the data type depending on the particular need at the moment.
In addition to the dual representation of data types, another aspect of the invention allows for the application of rules to determine when to use the boxed representation and when to use the value type (or unboxed) representation of a data type. These rules can be applied, for example, by a compiler and allow, among other things, for implicit conversion between the boxed and unboxed representations of a particular data type.
In another aspect of the invention, the unified view of the type system is reflected in the behavior of virtual methods for objects. One basic feature of objects is that they can inherit methods from “parent” objects. Such methods may include methods that take objects as arguments. The dual representation of value types both as value types and as objects in the hierarchy implies that value types can have methods and can behave as objects in some instances and as value types in other instances. Although the details are discussed more completely below, the practical effect is that when value types are in their boxed representation, they can possess type information like other objects. Furthermore, when value types are in their unboxed representation, they can be valid arguments to methods that would otherwise expect an object type (such as a boxed representation). This approach provides entirely new and powerful programming paradigms to developers. Furthermore, since both boxed and unboxed representations are available, all this functionality can be provided without the developer having to explicitly specify in the source code the value type version (i.e., boxed or unboxed) to use or the conversion from one form to another.
In one implementation of the present invention, a unified type system is provided in a runtime environment. A source code file includes an unboxed value type representation. Metadata is associated with the unboxed value type representation for converting the unboxed value type representation into a boxed value type representation. Output code is generated from the compiler converting between the unboxed value type representation and the boxed value type representation in response to a detection of different types in a runtime operation.
In another implementation of the present invention, a method for compiling a source file containing at least one unboxed value type representation is provided. It is determined that the source file includes the unboxed value type representation. Metadata is associated with the unboxed value type representation, responsive to the determining operation. An operation having operands with differing types is specified in the source file. One operand is the unboxed value type representation and another operand is a boxed value type representation. Output code is emitted from the compiler for converting one of the operands to match the type of the other operand.
In other implementations of the present invention, articles of manufacture are provided as computer program products. One embodiment of a computer program product provides a computer program storage medium readable by a computer system and encoding a computer program for compiling a source file containing at least one unboxed value type representation. Another embodiment of a computer program product may be provided in computer data signal embodied in a carrier wave by a computing system and encoding the computer program for compiling a source file containing at least one unboxed value type representation. The computer program product encodes a computer program for executing on a computer system a computer process for compiling a source file containing at least one unboxed value type representation. It is determined that the source file includes the unboxed value type representation. Metadata is associated with the unboxed value type representation, responsive to the determining operation. An operation having operands with differing types is specified in the source file. One operand is the unboxed value type representation and another operand is a boxed value type representation. Output code is emitted from the compiler for converting one of the operands match the type of the other operand.
In a further aspect of the invention, the notion can be combined with a runtime or execution environment to produce a unique runtime environment that supports value types, object classes, and interfaces.
These and various other features as well as advantages, which characterize the present invention, will be apparent from a reading of the following detailed description and a review of the associated drawings.
Exemplary embodiments of the present invention provide for a more unified view of the type system of programming languages, and object oriented programming languages in particular. An exemplary type system includes a dual representation for basic data types. One representation is the basic data type representation referred to as an unboxed value type or simply as a value type. An unboxed value type is generally not accompanied by type information in the output code emitted from a compiler. In an embodiment of the present invention, however, each of the basic data types also has a boxed representation that exists in the object hierarchy of the type system and is accompanied by type information (e.g., specified by metadata) in the output code emitted from the compiler.
This dual representation can also be extended to user-defined types, so that user-defined types may exist both as an unboxed value type and as an object (i.e., boxed value type) within the object hierarchy of the type system. This allows the compiler and/or runtime to select the most effective and efficient representation for the data type depending on the particular need at the moment.
In an alternative embodiment of the present invention, the source code of the source file 100 may first be translated into an intermediate language before being received by the compiler 104, as represented by an intermediate language code file 106. It should be understood that the following discussion addresses an embodiment in which source file 100 is input to the compiler 104, although it is contemplated that either source code or intermediate code may be input to the compiler 104 in an embodiment of the present invention. Likewise, both source code and intermediate code may have compatible structures and syntaxes for defining data and associated data types within the scope of the present invention.
Generally, a compiler is a program that translates source code (or intermediate language code) into object code or executable code. The compiler derives its name from the way it works, looking at an entire piece of source code and collecting and reorganizing the instructions and data therein. In some implementations, a second stage includes a linker that links the compiled object code with other object code to produce an executable program. In other implementations, this linking process is performed just prior to or during runtime and is referred to as “late binding” or “runtime binding”.
As discussed, programming languages typically have a notion of data types. Data within the source file 100 generally consists of two data types: (1) value types 110 and (2) objects 112.
For clarity, classes and object names as discussed herein are represented by capitalized names and value types and value type variable names are labeled with lower case names. Data may be defined in a source file as a “value type” using a variable name and an associated type indicator. For example, data representing an index may be defined as “int index;”, where “int” is the data type indicator and “index” is the variable name. Alternatively, data may be defined in a source file as an “object” using an object name, a class indicator, and a class definition. For example, the exemplary source code set forth below defines a class called Rect, comprising four Cartesian coordinates defining the four corners of a rectangle.
The statement “Rect RectObject” defines an object “RectObject” (the object name) of class “Rect” (the class indicator). Note that the RectObject may also include other objects and value types, such as objects “UpperLeft”, “UpperRight”, “LowerLeft”, and “LowerRight”, of class Cartesian (the class definition of which is not shown) and a value type “area” of data type “float”. It should also be understood that the discussion above merely represents an exemplary definition of data in a source file, and that alternative data structures and syntaxes of data definition are contemplated within the scope of the present invention.
The compiler 104 may include or have access to one or more of a variety of built-in data types, including built-in value types 114 and a basic object class hierarchy 116, and type rules 118 for converting between and defining the relationship between various data types. Generally, built-in value types represent value types that are believed to be fundamental to the programming language and commonly used by programmers, such as “int” for an integer, “char” for a character, and “float” for a floating point number.
Likewise, the basic object class hierarchy 116 includes fundamental and commonly used classes in an inheritance hierarchy. For example, a root class in the hierarchy may define a “BasicObject”, which includes fundamental characteristics (e.g., data and functions) of a basic object in the programming language. Children of the root class may be defined to “inherit” or “extend” the BasicObject class for more specific uses. For example, a “Shape” class and a “Point” class may inherit from the BasicObject class, and a “Rect” class and a “Circle” class may inherit from the “Shape” class. The combination of basic classes comprises an object class hierarchy. Another example object class hierarchy is illustrated in
In many programming languages, both built-in value types and basic classes may be extended or customized. For example, in C language, a developer may define a new value type using the keyword “typedef”. For example, a value type “coordinate” may be defined as a structure containing two floating point numbers representing X-Y coordinates on a Cartesian plane, as set forth below.
Likewise, source code may extend the basic object class hierarchy by inheriting or extending one or more of the basic classes. For example, a user-defined object may extend the basic Shape class to define a “CustomShape” class. Referring again to
In an embodiment of the present invention, the compiler 104 may include type rules 118 that provide the compiler with instructions for properly converting between different value types. For example, in C Language, a source code instruction may assign an integer value to a floating point variable (e.g., “float amount=total;”, where “total” is a data value of type integer and “amount” is a floating point number variable). The C compiler can apply the type rules 118 to automatically convert the integer “total” into a floating point number value before generating instructions for assigning the value to variable “amount”. Alternatively, the compiler 104 may not provide the appropriate type rule for a given value type combination and operation (e.g., assigning an “integer” value to a “coordinate” variable). In such situations, the compiler may issue a compiler error or throw a runtime exception to signal the error.
In an embodiment of the present invention, source code instructions for performing operations between value types and objects by boxing and/or unboxing one or both of the operands may be compiled and executed transparently to the developer. In a first example, a source code instruction indicates that a value with a value type is to be assigned to an object (e.g., a value with an “integer” value type is assigned to an object of the “Integer” class). To perform such an assignment without boxing would typically cause a compiler error because the types of the operands are not equivalent (i.e., the assignment does not satisfy a type rule). Without boxing/unboxing, a compiler does not perform the assignment because the “integer” value type is not associated with metadata required to populate the Integer object's metadata portion (see
Instead, the compiler 104 detects the discrepancy between types and generates metadata and compiler code to “box” the “integer” value, thereby converting the value type into an object, so that the boxed value type can be assigned to the Integer object. If the types include a built-in value type, the compiler may be pre-configured with the metadata required to box the value type. If the types include a user-defined value type, the user can provide the required metadata for the compiler to use in the boxing operation. The metadata defining a user-defined type may describe a sequence of bits (i.e., the value) and includes the type name, field names for all fields in the type, field types for all fields, and operations that can be performed in association with the type (e.g., methods). The metadata defining a user-defined type can also include a list of interfaces that the type will implement in its boxed form. Finally, the metadata can include an indication as to where a boxed version of the value type will fit within the object class hierarchy 116, described below in connection with
Rather than generate code to box and unbox value types at the compiler, other embodiments may implement the concept of dual representation in different ways. For example, if the runtime environment that is the target of the code (such as runtime environment 102) can box and unbox value types, then the compiler need only output a box or unbox command as appropriate and the runtime can perform the actual work. In other implementations, boxed and unboxed representations can exist simultaneously with no need for either the compiler or the runtime environment to generate code that boxes or unboxes value types. In other implementations, only the boxed representations may be generated with a mechanism to bypass or ignore the metadata portion when unboxed version is desired.
The output code 108 produced by the compiler 104 logically includes the compiled objects 120 and dual representation 126 of both boxed and unboxed representations (122 and 124) of the value types defined in the source file 100. In one embodiment, all value types are compiled to logically produce both boxed and unboxed representations. The dual representations of the value type itself may occupy effectively the same storage location or, in an alternative embodiment, in individual and distinct storage locations. In another embodiment, only those value types interacting with objects are to be boxed, thereby reducing the size of the output code 108 (i.e., unnecessary metadata is omitted). Furthermore, another embodiment of the present invention may retain a single version of the value type (i.e., boxed or unboxed) at a time, converting dynamically between the two versions, as needed. As such, only one version of the value type need be maintained at any one time, the value type version being dynamically converted by code generated by the compiler in accordance with a given operation (e.g., an assignment, a function call with object parameters, etc.).
In addition, the output code 108 may include metadata associated with a value type. Alternatively, the output 108 may include a machine or executable code representation of the object created by the boxing operation. In yet another alternative, the machine or executable code representation may be generated at runtime, as discussed below.
Another example of source code instructions performing operations between value types and objects by boxing and/or unboxing is provided in the case in which a boxed value type is to be assigned to a value with a unboxed value type (e.g., an object of the Integer class is assigned to a value with an integer value type). To perform such an assignment without unboxing would typically cause a compiler error because the types of the operands are not equivalent.
In an embodiment of the present invention, however; the compiler 104 detects the discrepancy between types and generates code to convert the object to an unboxed value type by deleting or ignoring the metadata associated with the boxed value type, so that the unboxed value type can be assigned to the “integer” value type.
With reference to
A number of program modules may be stored in the drives and RAM 25, including an operating system 35, a source file 100, a Runtime System 102, and a compiler 104. A user may enter commands and information into the personal computer 20 through a keyboard 40 and pointing device, such as a mouse 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a game port or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers or printers.
The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be a server, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the personal computer 20, although only a memory storage device 50 has been illustrated in
When used in a LAN networking environment, the personal computer 20 is connected to the LAN 51 through a network interface 53. When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the WAN 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
Computing device, such as personal computer 20, typically includes at least some form of computer readable media. Computer readable media can be any available media that can be accessed by personal computer 20. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. 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. 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 be accessed by personal computer 20. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media. Computer readable media may also be referred to as computer program product.
As described above, in connection with
An exemplary list of data types is depicted in
A user can create metadata to describe a boxed form of a value type. For example, the process of creating a user-defined value type may include a step of specifying the metadata for that type needed for boxing a value type. Typically, the metadata defining a user-defined type 304 describes a sequence of bits (i.e., the value) and includes the type name, field names for all fields in the type, field types for all fields, and operations that can be performed in association with the type (e.g., methods). The metadata defining a user-defined type can also include a list of interfaces that the type will implement in its boxed form. Finally, the metadata can include an indication as to where a boxed version of the type will fit within the object class hierarchy 116, described below in connection with
The object class hierarchy of
Notably, a “child” object, such as Object y, inherits the attributes of a “parent” object, such as Object x. If a method is associated with Object x, for example, then the method is also associated with Object y, by inheritance. One aspect illustrated in
The dual representation of value types both as unboxed value types and as boxed value types in the object class hierarchy implies that value types can have methods and can behave as objects in some instances and as unboxed value types in other instances. The practical effect is that when value types are in their boxed representation, they can have methods like other objects. When value types are in their unboxed representation, they can be valid arguments to methods that would otherwise expect an object type (such as a boxed representation). Because both the boxed and unboxed value type representations can be made available, this functionality can be provided without the developer having to explicitly specify either what version to use or the conversion from one form to another.
A data type fully describes a value if it completely defines the value's representation and the operations that can be performed on the value. For a data type, defining the value's representation entails describing the sequence of bits that make up the value's representation. Defining the set of operations that can be performed on a data type entails specifying named methods for each operation. A named method describes an operation that can be performed in association with a data type.
For an object, defining the object's representation entails describing the object's location and the sequence of bits that make up the object's representation. Thus an object includes a definition of the object's contents and the operations that may be performed on that object. When an object contains a value, this definition includes the value's representation and the operations that can be legally performed in association with the value (e.g., methods). Defining an object entails describing the sequence of bits that make up the value's representation (self describing data), the location of the object (pointer data), and at least one named method for the object (interface data).
Thus, an object differs from an unboxed data type, in that an object includes not just raw data (i.e., a value representation), but also other data including the location of the object. This other data is stored in the object as metadata. Advantageously, metadata can be stored in a way that is independent of any particular programming language. Thus, metadata provides a common interchange mechanism for use between tools that manipulate objects (e.g., compilers, debuggers).
Turning now to
Functional software components of another system 500 that incorporates aspects of the present invention are shown in
In an exemplary embodiment of the present invention, the common language output files 514, 516 and 518 have executable instructions in a “common” (in the sense of universal) intermediate language suitable for representing the concepts of a plurality of different types of source languages, e.g., procedural, functional and object oriented languages, so that only one type of intermediate language need be used regardless of the specific source language used. The executable instructions within the common language output files 514, 516 and 518 can be either instructions that can be directly executed by a processor (e.g., object or native machine code) or an “intermediate” type instruction (e.g. Java bytecodes, p-code, or other intermediate language) that is executed within some type of execution environment.
The front end compilers 502, 504 and 506, in addition to being able to read and analyze their respective source files 508, 510 and 512, are capable of reading and analyzing files represented in the common language. Moreover, a library declarations file 520 of functions represented in the common language is available for use by the front end compilers 502, 504 and 506.
The common language files 514, 516 and 518, once compiled, may be transmitted to an execution environment or runtime environment 522. In this application, execution environment and runtime environment are used interchangeably. The execution environment may be either a direct execution environment, a managed runtime environment or an unmanaged runtime environment. Advantageously, any necessary conversions of unboxed value types to boxed value types (or vice versa) may be performed either at the compiler stage, thereby permitting the use of such converted value types without regard to the managed or unmanaged status of the runtime environment, or by the runtime environment. Indeed, the environment may be any other type of environment capable of reading and executing the compiled files 514, 516 and 518. The runtime environment 522 shown in
Prior to being supplied to the runtime environment 522, each output file 514, 516 and 518 may undergo optional processing as illustrated by the separate optional processing section 524 or the integral optional processing section 526. Generally, optional processing may involve verification, type checking, and or any translation of the common language file into a form suitable for use by the runtime environment 522. Hence, optional processing may be used to translate, interpret or otherwise convert the received common output files 514, 516 and 518, into output code that can be executed in the execution environment 522.
In the case where the execution environment 522 is a managed runtime environment as shown in
The execution environment 522 may further utilize a common library program file 528, which has the actual implementation information to carry out the functionality of the common library declarations 520.
During runtime, the output files 514, 516 and 518 are loaded into the runtime environment 522. Importantly, the information that is provided to the runtime environment, such as the boxed or unboxed value types shown in
The logical operations in
In one embodiment of the present invention, the operations of
The boxed value type can include the definition of the type name, the field names, field types, and operations that can be performed in association with the boxed value type (e.g., methods). Creation of the boxed value type can also include the creation of metadata representing the appropriate position of the boxed value type in an object class hierarchy and any relationships with other boxed value types.
Notably, boxed test operation 610 is also reached if a determination is made at unboxed test operation 602 that the source file does not include a trigger requiring an unboxed to boxed conversion. Boxed test operation 610 detects whether the source file includes a conversion trigger requiring a boxed to unboxed conversion. If the source file does not include a conversion trigger requiring an unboxed to boxed conversion, then the operation flow branches NO to step 612 and ends for the converted value type.
On the other hand, if boxed test operation 610 detects that the source file includes a conversion trigger requiring a boxed to unboxed conversion, then the operation flow branches YES to boxed value type emit operation 614. The boxed value type emit operation 614 emits code to perform the boxed to unboxed conversion, the boxed value type, and the metadata associated with the boxed value type to the runtime environment via the output code. The operation flow then proceeds to conversion operation 616 and converts or builds an unboxed value type from the code to perform the boxed to unboxed conversion, the boxed value type, and the metadata associated with the boxed value type in the output code.
A boxed to unboxed conversion trigger can be any entity in the source file that indicates that the conversion is needed. Examples of conversion triggers include situations where a boxed value type is assigned to an unboxed value type and where a boxed value type is passed to an object expecting an unboxed value type. In both of these example cases, a boxed to unboxed conversion would be required. The operation flow proceeds to step 618 and ends with regard to the converted value type.
It will be appreciated that the operation of
As discussed, the process described with regard to
In an alternative embodiment of the present invention, however, the detecting operations 602 and 610 and the emitting operations 604 and 614 may also be performed during runtime. The “emitting” operations are embodied by a call to boxing or unboxing code during runtime. Such an embodiment is disclosed with regard to
During execution of the object code 106 (
Once the value type has been defined, pass operation 704 passes the defined value type to a particular function. In essence during compile time, the compiler emits code to provide for the passing of the value type to the function during runtime. Passing a parameter of this sort to a function is straightforward and effectively provides the necessary value type information to the function for operation.
The particular function that receives the defined value type expects either a boxed or unboxed value type. Therefore, following the passing operation 704, determination act 706 determines whether the passed value type is the same as the expected value type. The determination may be a simple testing of a bit associated with the value type or some other operation that evaluates the type of data passed to the function.
If determination operation 706 determines that the passed value type is not the same as the expected value type, flow branches NO to modify operation 708. Modify operation either boxes or unboxes the passed value type, and passes the new value type to the function. In an embodiment where the function expected a boxed value type but received an unboxed value type, step 708 boxes the value type. On the other hand, had the function expected an unboxed value type but received a boxed value type, then operation 708 would unbox the value type. The result of the box operation 708 is a pointer to an object describing the unboxed value type. Following the modification operation 708, flow continues with call operation 710, which is described below.
If the determination step 706 determined that the passed value type was the same as the expected value type, then flow branches YES to call operation 710. Essentially, had the function received a value type that was expected, no modification, such as modification operation 708, would be necessary. Thus, flow continues with call operation 710.
Call operation 710 calls a member method associated with the defined function. The method may be a virtual method, e.g., wherein the compiler could not determine one certain method to call at compile time and therefore implemented multiple versions, such as in the case with superclasses or in the case wherein the function may receive both boxed and unboxed versions of value types. The member method is related to a user defined method for operating on the passed value type. At compile time, the compiler emits the code for performing the various methods within the function. However, since the function may receive different types, the compiler does not insert the specific code within the function for each type. Instead, the compiler creates a virtual method table. The virtual method table comprises the necessary information to perform the method for each of the specific value types that the function may receive.
Therefore, once the method has been called at 710, the runtime environment executes the method call using the reference to the appropriate method in the virtual method table. More specifically, lookup operation 712 looks up the particular method related to the passed value type. Once the particular method for that type is found, execute operation 714 executes the method for that value type.
As stated, the above-described flow of operations is able to handle either boxed or unboxed parameters. A key feature relates to the use of a virtual table to provide methods for the different value types that may be passed to a particular function. Since the function may receive different types and since the compiler is unaware of which type the function will receive, the runtime environment performs the necessary analysis and resolves any discrepancies between value types.
A flow 800 of operations in an alternative embodiment to that shown in
Once passed, call operation 806 then calls the member function. This act is similar to call operation 710 described above wherein the actual method is called. Following the call operation 806, lookup operation 808 looks up the called method for the passed value type in the virtual method table. Lookup operation 808 is similar to operation 712 described above.
Following call operation 806 and lookup operation 808, determination act 810 determines whether the passed value type is the same as the expected value type. Determination act 810 is similar to the determination act 706 described above in that the passed value type is analyzed against the expected form of the value type. One difference, however, is that the code for performing the determination act may actually reside in the front portion of the called method code, as described below.
If the determination act 810 determines that the passed value type is different from the expected form, then flow branches NO to modify operation 812. Modify operation 812 is similar to modify operation 708 described above in conjunction with
If, on the other hand, determination act 810 determines that the passed value type is the same as the expected value type, then execute operation 814 performs the method using the passed value type. Since the passed value type was the same as the expected value type, then no modification act, such as act 812, is needed prior to execution.
The embodiment shown in
Thus, the present invention is presently embodied as a method, apparatus, or article of manufacture, such as computer readable media or program product containing a computer program, for processing objects of various programming languages and for boxing and unboxing a user-defined data type. While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various other changes in the form and details may be made therein without departing form the spirit and scope of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5339424||Apr 17, 1992||Aug 16, 1994||Mitsubishi Denki Kabushiki Kaisha||System and method for compiling and executing a computer program written in more than one programming language|
|US5375242||Sep 29, 1993||Dec 20, 1994||Hewlett-Packard Company||Compiler architecture for cross-module optimization|
|US5577253||Mar 6, 1995||Nov 19, 1996||Digital Equipment Corporation||Analyzing inductive expressions in a multilanguage optimizing compiler|
|US5613117||Apr 20, 1994||Mar 18, 1997||Digital Equipment Corporation||Optimizing compiler using templates corresponding to portions of an intermediate language graph to determine an order of evaluation and to allocate lifetimes to temporary names for variables|
|US5659753||Dec 27, 1994||Aug 19, 1997||Digital Equipment Corporation||Interface for symbol table construction in a multilanguage optimizing compiler|
|US5689703||Jun 6, 1995||Nov 18, 1997||Microsoft Corporation||Method and system for referring to and binding to objects using identifier objects|
|US5873097||Dec 17, 1996||Feb 16, 1999||Apple Computer, Inc.||Update mechanism for computer storage container manager|
|US5889992||Mar 28, 1996||Mar 30, 1999||Unisys Corp.||Method for mapping types stored in a model in an object-oriented repository to language constructs for A C binding for the repository|
|US5923882||Aug 29, 1995||Jul 13, 1999||Silicon Graphics, Inc.||Cross-module optimization for dynamically-shared programs and libraries|
|US5937409 *||Jul 25, 1997||Aug 10, 1999||Oracle Corporation||Integrating relational databases in an object oriented environment|
|US5987242||Nov 10, 1997||Nov 16, 1999||Bentley Systems, Incorporated||Object-oriented computerized modeling system|
|US5987247||May 9, 1997||Nov 16, 1999||International Business Machines Corporation||Systems, methods and computer program products for building frameworks in an object oriented environment|
|US6058455||Mar 27, 1998||May 2, 2000||International Business Corporation||RAID system having a selectable unattended mode of operation with conditional and hierarchical automatic re-configuration|
|US6061690||Oct 31, 1997||May 9, 2000||Oracle Corporation||Apparatus and method for storage of object collections in a database system|
|US6067413||Jun 13, 1996||May 23, 2000||Instantations, Inc.||Data representation for mixed-language program development|
|US6101502||Sep 25, 1998||Aug 8, 2000||Ontos, Inc.||Object model mapping and runtime engine for employing relational database with object oriented software|
|US6246403 *||Oct 8, 1998||Jun 12, 2001||Hewlett-Packard Company||Method and apparatus for generating a graphical user interface|
|US6260074 *||Mar 30, 1996||Jul 10, 2001||Sun Microsystems, Inc.||Method and apparatus for passing generic objects in a distributed system|
|US6282670||Jun 22, 1998||Aug 28, 2001||International Business Machines Corporation||Managing defective media in a RAID system|
|US6336161||Dec 15, 1995||Jan 1, 2002||Texas Instruments Incorporated||Computer configuration system and method with state and restoration from non-volatile semiconductor memory|
|US6353452 *||Oct 20, 1998||Mar 5, 2002||International Business Machines Corporation||Data item display method and device, and recording medium storing a program for controlling display of data item|
|US6370682||Oct 29, 1999||Apr 9, 2002||Siemens Atkiengesellschaft||System and method for developing reusable flexible and platform independent software using components|
|US6381735||Nov 20, 1998||Apr 30, 2002||Microsoft Corporation||Dynamic classification of sections of software|
|US6457172||Apr 13, 1999||Sep 24, 2002||International Business Machines Corporation||Compiler for supporting multiple runtime data representations|
|US6523027 *||Jul 30, 1999||Feb 18, 2003||Accenture Llp||Interfacing servers in a Java based e-commerce architecture|
|US6560699||Oct 20, 1999||May 6, 2003||Cisco Technology, Inc.||Constraint-based language configuration files for updating and verifying system constraints|
|US6601233 *||Jul 30, 1999||Jul 29, 2003||Accenture Llp||Business components framework|
|US6609128 *||Jul 30, 1999||Aug 19, 2003||Accenture Llp||Codes table framework design in an E-commerce architecture|
|US6738968 *||Jul 11, 2000||May 18, 2004||Microsoft Corporation||Unified data type system and method|
|US6836883||Jun 21, 2000||Dec 28, 2004||Microsoft Corporation||Method and system for compiling multiple languages|
|US6915324 *||Apr 21, 2000||Jul 5, 2005||Sun Microsystems, Inc.||Generic and dynamic mapping of abstract syntax notation (ASN1) to and from interface definition language for network management|
|US7735071||Jul 12, 2004||Jun 8, 2010||Microsoft Corporation||Method and system for compiling multiple languages|
|US20040143823||Jan 9, 2004||Jul 22, 2004||Wei Coach K.||System and method for network-based computing|
|GB1367741A||Title not available|
|JPH03102427A||Title not available|
|WO1999042925A1||Feb 18, 1999||Aug 26, 1999||Cygnus Solutions||Java development environment using optimizing ahead-of-time compiler|
|1||*||"Software Systems Constructions with Examples in ADA" by Bo Sanden, (7 pages) pp. 104-109, published 1994.|
|2||A.D. Gordon and D. Syme, Typing a multi-language intermediate code. Submitted to The 28th ACM Principles of Programming Languages, (Feb. 2001), pp. 1-9.|
|3||Advisory Action dated Feb. 5, 2008 issued in U.S. Appl. No. 10/889,924, 4 pgs.|
|4||Advisory Action dated Oct. 14, 2003 filed in U.S. Appl. No. 09/598,105.|
|5||Amendment After Notice of Allowance dated Apr. 26, 2010 filed in U.S. Appl. No. 10/889,924, 6 pgs.|
|6||Andrew Johnson, James Loveluck and Ira Goldstein; The ANDF Technology Program at the OSF RI; Dec. 8, 1992, 6 pgs.|
|7||Appeal Decision dated Dec. 3, 2010 issued in Japanese Application No. 2001-209530 (translated), 4 pgs.|
|8||Appel et al., "Scaling Proof-Carrying Code to Production Compilers and Security Policies", Jan. 1999, DARPA-.|
|9||Appel et al., "The Zephyr Compiler Infrastructure", Nov. 1998, http://www.cs.virginia.edu/zephyr/, pp. 1-10.|
|10||Burnett et al, Visual Object-Oriented Programming, pp. 1-42, 199-274, published 1994 (2 parts), 130 pgs.|
|11||C Magazine, vol. 2, No. 1, p. 112, SOFTBANK Japan Corp., Japan, Jan. 1, 1990, 1 pg.|
|12||Christian Fabre, Francois de Ferriere, Fred Roy; Java-ANDF Feasibility Study Final Report; Mar. 26, 1997, 12 pgs.|
|13||Decision to Decline the Amendment dated Aug. 13, 2010 issued in Japanese Application No. 2001-209530 (translated), 7 pgs.|
|14||Decision to Decline the Amendment dated Jan. 8, 2010 issued in Japanese Application No. 2007-287939 (translated), 4 pgs.|
|15||Decision to Refuse a European Patent Application dated Mar. 10, 2008 issued in European Application No. 01 115 100, 17 pgs.|
|16||*||Deitel & Deitel "C++ How to Program", Second Edition, pp. 192-194, Published 1998, 1994.|
|17||Dr. N.E. Peeling; ANDF Features and Benefits; Feb. 5, 1993, 9 pgs.|
|18||EPO Communication dated Feb. 13, 2008 issued in European Application No. 01 11 6860, 8 pgs.|
|19||EPO Communication dated Jun. 12, 2006 issued in European Application No. 01 115 100, 13 pgs.|
|20||European Search Report for EP 01 11 6860 dated Jul. 31, 2007.|
|21||GNU Development Tools, manual page of ar (http://www.freebsd.org/cgi/man.cgi?query=ar&apropos=0&sektion=0&manpath=FreeBSD+4.8-RELEASE&format=html), 1999, 5 pgs.|
|22||GNU Tools, manual page of GCC (http://www.freebsd.org/cgi/man.cgi?query=gcc&apropos=0&sektion=0&manpath=FreeBSD+4. 8-RELEASE&format=html), Dec. 16, 1998, 34 pgs.|
|23||Gosling et al, "The Java Language Environment. A White Paper", Sun Microsystems Computer Company, Oct. 1, 1995, pp. 1, 4-85, XP 002042922, 86 pgs.|
|24||Henglein, Fritz & Jorgensen, Jasper, "Formally Optimal Boxing," Proceedings of the 21st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 1994, pp. 213-216.|
|25||Interrogation dated Dec. 18, 2009 issued in Japanese Application No. 2001-209530 (translated), 7 pgs.|
|26||*||James O. Coplien Ed, "Advanced C++ programming styles and idioms; IDSBN: 0-201-54855-0" 1992, Reeding, Addition Wesley, US, pp. 43 92-93, 108, XP002148185, *p. 135, Line 15-Last Line*, *p. 137, Figure 5-6*.|
|27||Lindholm, Tim & Yellin, Frank, "The Java Virtual Machine Specification, Second Edition," Sun Microsystems, 1999, Ch. 2, pp. 1-44.|
|28||M. Tofte and J.P. Talpin, Region-based memory management. Information and Computation, 1997, 132(2), pp. 109-176.|
|29||*||Microsoft Corporation, "C# Version 2.0 Specification", pp. 1-100, May 2004.|
|30||Minutes of Oral Proceedings dated Dec. 28, 2007 issued in European Application No. 01 115 100, 12 pgs.|
|31||Notice of Allowance dated Dec. 24, 2010 issued in Japanese Application No. 2007-287939 (translated), 6 pgs.|
|32||Notice of Allowance dated Jan. 26, 2010 issued in U.S. Appl. No. 10/889,924, 5 pgs.|
|33||Notice of Allowance dated Jun. 3, 2004 filed in U.S. Appl. No. 09/598,105.|
|34||Notice of Rejection dated Apr. 21, 2009 issued in Japanese Application No. 2007-287939 (translated), 9 pgs.|
|35||Notice of Rejection dated Aug. 6, 2010 issued in Japanese Application No. 2001-209530 (translated), 29 pgs.|
|36||Notice of Rejection dated Jan. 8, 2010 issued in Japanese Application No. 2007-287939 (translated), 2 pgs.|
|37||Notice of Rejection dated Jul. 6, 2007 issued in Japanese Application No. 2001-209530 (translated), 7 pgs.|
|38||Notice of Rejection dated Mar. 2, 2007 issued in Japanese Application No. 2001-209530 (translated), 13 pgs.|
|39||Notice of Rejection dated Sep. 11, 2009 issued in Japanese Application No. 2007-287939 (translated), 6 pgs.|
|40||Notice of Rejection dated Sep. 3, 2010 issued in Japanese Application No. 2007-287939 (translated), 3 pgs.|
|41||Notice of Rejection issued in 2007 in Japanese Application No. 2001-164625 (translated).|
|42||Notice of Rejection issued in Aug. 2007 in Japanese Application No. 2001-164625 (translated).|
|43||Office Action dated Apr. 13, 2009 issued in U.S. Appl. No. 10/889,924, 9 pgs.|
|44||Office Action dated Jan. 26, 2004 filed in U.S. Appl. No. 09/598,105.|
|45||Office Action dated Jul. 15, 2003 filed in U.S. Appl. No. 09/598,105, 11 pgs.|
|46||Office Action dated May 1, 2008 issued in U.S. Appl. No. 10/889,924, 11 pgs.|
|47||Office Action dated May 30, 2007 issued in U.S. Appl. No. 10/889,924, 27 pgs.|
|48||Office Action dated Nov. 10, 2008 issued in U.S. Appl. No. 10/889,924, 11 pgs.|
|49||Office Action dated Nov. 13, 2007 issued in U.S. Appl. No. 10/889,924, 30 pgs.|
|50||Office Action dated Nov. 21, 2002 issued in U.S. Appl. No. 09/598,105, 11 pgs.|
|51||Rational Rose/C++, Rational Software Corporation, whole manual, released 1996 (2 parts), 210 pgs.|
|52||Response to Advisory Action dated Feb. 13, 2008 filed in U.S. Appl. No. 10/889,924, 7 pgs.|
|53||Response to Amendment After Notice of Allowance dated May 4, 2010 issued in U.S. Appl. No. 10/889,924, 3 pgs.|
|54||Response to EPO Communication dated Aug. 26, 2008 filed in European Application No. 01 11 6860, 18 pgs.|
|55||Response to EPO Communication dated Oct. 23, 2006 issued in European Application No. 01 115 100.|
|56||Response to Office Action dated Apr. 26, 2004 filed in U.S. Appl. No. 09/598,105.|
|57||Response to Office Action dated Aug. 1, 2008 filed in U.S. Appl. No. 10/889,924, 11 pgs.|
|58||Response to Office Action dated Aug. 13, 2009 filed in U.S. Appl. No. 10/889,924, 8 pgs.|
|59||Response to Office Action dated Aug. 30, 2007 filed in U.S. Appl. No. 10/889,924, 36 pgs.|
|60||Response to Office Action dated Dec. 12, 2003 filed in U.S. Appl. No. 09/598,105.|
|61||Response to Office Action dated Feb. 10, 2009 filed in U.S. Appl. No. 10/889,924, 11 pgs.|
|62||Response to Office Action dated Jan. 11, 2008 filed in U.S. Appl. No. 10/889,924, 16 pgs.|
|63||Response to Office Action dated Mar. 21, 2003 filed in U.S. Appl. No. 09/598,105, 27 pgs.|
|64||Response to Office Action dated Sep. 15, 2003 filed in U.S. Appl. No. 09/598,105, 11 pgs.|
|65||Response to Summons to attend oral proceedings dated Nov. 9, 2007 issued in European Application No. 01 115 100, 20 pgs.|
|66||Result of consultation dated Dec. 12, 2007 issued in European Application No. 01 115 100, 5 pgs.|
|67||Result of consultation dated Dec. 21, 2007 issued in European Application No. 01 115 100, 3 pgs.|
|68||S. Peyton Jones and J. Launchbury, Unboxed values as first class citizens. In Functional Programming Languages and Computer Architecture, vol. 523 of Lecture Notes in Computer Science, Springer-Verlag, 1991, pp. 636-666.|
|69||Schmidt and Voller, "A Multi-Language Compiler System with Automatically Generated Codegenerators", 1984, ACM, pp. 202-212.|
|70||Schmidt and Voller, "Experience With VDM in NORSK Data", 1987, VDM-Europe Symposium, Brussels, Belgium, pp. 50-62.|
|71||Shao, Zhong, "Flexible Representation Analysis," Proceedings of the second ACB SIGPLAN International Conference on Functional Programming, 1997, pp. 85-98.|
|72||*||SNAP Foundation Template Using the SNAP Language Version 8.0, Template Software, Inc.|
|73||SNAP-Using the SNAP Language, Template Software, Chapter 7, published 1997, 35 pgs.|
|74||SNAP—Using the SNAP Language, Template Software, Chapter 7, published 1997, 35 pgs.|
|75||Statement of grounds for Appeal dated Jul. 18, 2008 issued in European Application No. 01 115 100, 28 pgs.|
|76||Summons to attend oral proceedings dated Sep. 19, 2007 issued in European Application No. 01 115 100, 9 pgs.|
|77||Supplemental Amendment dated Oct. 27, 2009 filed in U.S. Appl. No. 10/889,924, 8 pgs.|
|78||Supplemental Response to Office Action dated Dec. 15, 2003 filed in U.S. Appl. No. 09/598,105.|
|79||Thiemann, Peter, "Unboxed values and polymorphic typing revisiting," Proceedings of the 7th International Conference on Functional Programming Languages and Computer Architecture, 1995, pp. 24-35.|
|80||U.S. Appl. No. 09/598,105, Titled: Method and System for Compiling Multiple Languages, filed Jun. 21, 2000.|
|81||X. Leroy. Unboxed objects and polymorphic. In 19th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, ACM Press, 1992, pp. 177-0188.|
|82||Y.G. Park and B. Goldberg, Escape analysis on lists. In ACM SIGPLAN Conference on Programming Language Design and Implementation, ACM Press, 1992, pp. 116-127.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8392888 *||Aug 31, 2010||Mar 5, 2013||International Business Machines Corporation||Method of translating n to n instructions employing an enhanced extended translation facility|
|US8788542||Feb 12, 2008||Jul 22, 2014||Oracle International Corporation||Customization syntax for multi-layer XML customization|
|US8799319||Jun 18, 2009||Aug 5, 2014||Oracle International Corporation||System and method for meta-data driven, semi-automated generation of web services based on existing applications|
|US8875306||Feb 12, 2008||Oct 28, 2014||Oracle International Corporation||Customization restrictions for multi-layer XML customization|
|US8954942 *||Jan 27, 2012||Feb 10, 2015||Oracle International Corporation||Optimizations using a BPEL compiler|
|US8966465||Feb 12, 2008||Feb 24, 2015||Oracle International Corporation||Customization creation and update for multi-layer XML customization|
|US8984497 *||Dec 18, 2012||Mar 17, 2015||International Business Machines Corporation||Source code converting, method program, and systems for first programming language to a code in a second programming language|
|US8996658||Sep 3, 2008||Mar 31, 2015||Oracle International Corporation||System and method for integration of browser-based thin client applications within desktop rich client architecture|
|US9122520||Sep 17, 2008||Sep 1, 2015||Oracle International Corporation||Generic wait service: pausing a BPEL process|
|US9262135 *||Jun 20, 2014||Feb 16, 2016||Optumsoft, Inc.||Interpreter-based program language translator using embedded interpreter types and variables|
|US20100325401 *||Aug 31, 2010||Dec 23, 2010||International Business Machines Corporation||Method of Translating N to N Instructions Employing an Enhanced Extended Translation Facility|
|US20130086568 *||Jan 27, 2012||Apr 4, 2013||Oracle International Corporation||Optimizations using a bpel compiler|
|US20130174131 *||Dec 18, 2012||Jul 4, 2013||International Business Machines Corporation||Code converting method, program, and system|
|US20150012912 *||Jun 20, 2014||Jan 8, 2015||Optumsoft, Inc.||Interpreter-based program language translator using embedded interpreter types and variables|
|U.S. Classification||717/141, 717/120|
|International Classification||G06F9/44, G06F9/45|
|Cooperative Classification||G06F8/437, G06F9/4428|
|European Classification||G06F8/437, G06F9/44F2|
|Dec 9, 2014||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034541/0477
Effective date: 20141014
|Apr 24, 2015||FPAY||Fee payment|
Year of fee payment: 4