U.S. patent application number 12/339556 was filed with the patent office on 2010-06-24 for providing access to a dataset in a type-safe manner.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to John Duffy, Igor Ostrovsky.
Application Number | 20100162211 12/339556 |
Document ID | / |
Family ID | 42267988 |
Filed Date | 2010-06-24 |
United States Patent
Application |
20100162211 |
Kind Code |
A1 |
Ostrovsky; Igor ; et
al. |
June 24, 2010 |
PROVIDING ACCESS TO A DATASET IN A TYPE-SAFE MANNER
Abstract
A method of providing access to a dataset in a type-safe manner
includes storing a dataset including a plurality of data elements
and a corresponding plurality of order keys for indicating an
ordering of the data elements. Each order key is associated with
one of the data elements. An interface to the dataset is generated
that is parameterized by an element type parameter and a key type
parameter. The interface is configured to provide access to the
data elements and the order keys in the dataset in a type-safe
manner.
Inventors: |
Ostrovsky; Igor; (Bellevue,
WA) ; Duffy; John; (Renton, WA) |
Correspondence
Address: |
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND
WA
98052
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
42267988 |
Appl. No.: |
12/339556 |
Filed: |
December 19, 2008 |
Current U.S.
Class: |
717/114 |
Current CPC
Class: |
G06F 8/437 20130101 |
Class at
Publication: |
717/114 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Claims
1. A method of providing access to a dataset in a type-safe manner,
comprising: storing a dataset including a plurality of data
elements and a corresponding plurality of order keys for indicating
an ordering of the data elements, each order key associated with
one of the data elements; and generating an interface to the
dataset that is parameterized by an element type parameter and a
key type parameter, wherein the interface is configured to provide
access to the data elements and the order keys in the dataset in a
type-safe manner.
2. The method of claim 2, and further comprising: performing an
operation configured to operate on the dataset via the interface,
wherein the operation is configured to be statically checked by a
compiler to verify that accesses to the dataset by the operation
are type-safe.
3. The method of claim 2, wherein the operation is parameterized by
an element type parameter and a key type parameter.
4. The method of claim 2, wherein the operation is configured to
perform at least one of changing an ordering of the data elements
in the dataset, changing a value of at least one of the data
elements in the dataset, adding data elements to the dataset, and
removing data elements from the dataset.
5. The method of claim 1, wherein the interface includes a generic
enumerator method parameterized by an element type parameter and a
key type parameter.
6. The method of claim 5, wherein the generic enumerator method is
configured to return an enumerator for enumerating over pairs of
data elements and corresponding order keys in the dataset.
7. The method of claim 1, wherein the interface includes a generic
compare method parameterized by a key type parameter, and wherein
the generic compare method is configured to compare two of the
order keys in the dataset and determine a smaller one of the two
order keys.
8. The method of claim 1, wherein the interface is implemented as a
generic class.
9. The method of claim 8, wherein the element type parameter and
the key type parameters are generic type parameters.
10. The method of claim 1, wherein the interface is a first generic
class that inherits from a second generic class that is
parameterized solely by an element type parameter.
11. The method of claim 10, and further comprising: performing an
operation configured to generate a generic action object and pass
the generic action object to the second generic class; forwarding
the generic action object from the second generic class to the
first generic class; and executing the generic action object with
the first generic class, thereby executing the generic action
object in a context in which types of the order keys are statically
available.
12. A computer-readable storage medium storing computer-executable
instructions for performing a method comprising: storing a dataset
including a plurality of data elements and a corresponding
plurality of order keys for indicating an ordering of the data
elements, each order key associated with one of the data elements;
and generating an interface to the dataset that is parameterized by
an element type parameter and a key type parameter, wherein the
interface is configured to provide access to the data elements and
the order keys in the dataset in a type-safe manner.
13. The computer-readable storage medium of claim 12, wherein the
method further comprises: performing an operation configured to
operate on the dataset via the interface, wherein the operation is
configured to be statically checked by a compiler to verify that
accesses to the dataset by the operation are type-safe.
14. The computer-readable storage medium of claim 13, wherein the
operation is parameterized by an element type parameter and a key
type parameter.
15. The computer-readable storage medium of claim 13, wherein the
operation is configured to perform at least one of changing an
ordering of the data elements in the dataset, changing a value of
at least one of the data elements in the dataset, adding data
elements to the dataset, and removing data elements from the
dataset.
16. The computer-readable storage medium of claim 12, wherein the
interface includes a generic enumerator method parameterized by an
element type parameter and a key type parameter.
17. The computer-readable storage medium of claim 16, wherein the
generic enumerator method is configured to return an enumerator for
enumerating over pairs of data elements and corresponding order
keys in the dataset.
18. The computer-readable storage medium of claim 12, wherein the
interface includes a generic compare method parameterized by a key
type parameter, and wherein the generic compare method is
configured to compare two of the order keys in the dataset and
determine a smaller one of the two order keys.
19. The computer-readable storage medium of claim 12, wherein the
interface is implemented as a generic class, and wherein the
element type parameter and the key type parameters are generic type
parameters.
20. A method of providing access to a dataset in a type-safe
manner, comprising: storing a dataset including a plurality of data
elements and a corresponding plurality of order keys for indicating
an ordering of the data elements, each order key associated with
one of the data elements; generating an interface to the dataset,
wherein the dataset is implemented as a generic class that is
parameterized by a generic element type parameter and a generic key
type parameter, and wherein the interface is configured to provide
access to the data elements and the order keys in the dataset in a
type-safe manner; and performing an operation configured to operate
on the dataset via the interface, wherein the operation is
parameterized by a generic element type parameter and a generic key
type parameter and is configured to be statically checked by a
compiler to verify that accesses to the dataset by the operation
are type-safe.
Description
BACKGROUND
[0001] A type system is a system used in programming languages to
aid in the detection and prevention of run-time errors. A
programming language is "typed" if it contains a set of types that
are declared for objects such as variables, functions, etc., and
these types are checked versus a set of rules during compilation of
a program written in the language. If the source code written in
the typed language violates one of the type rules, a compiler error
is determined. The process of verifying and enforcing type
constraints (also referred to as type checking), may occur either
at compile-time (i.e., static type checking) or run-time (dynamic
type checking).
SUMMARY
[0002] This summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used to limit the scope of the claimed
subject matter.
[0003] For a lazily ordered dataset, ordering information is stored
explicitly, in addition to the elements. Typically, for each
element, the lazily ordered data set also stores an associated
order key. Ordering of the order keys determines the ordering of
their associated elements.
[0004] One embodiment provides a method of providing access to a
lazily ordered dataset in a type-safe manner. A dataset including
data elements and order keys for indicating an ordering of the data
elements is stored. Each order key is associated with one of the
data elements. An interface to the dataset is generated that is
parameterized by an element type parameter and a key type
parameter. The interface provides access to the data elements and
the order keys in the dataset in a type-safe manner.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The accompanying drawings are included to provide a further
understanding of embodiments and are incorporated in and constitute
a part of this specification. The drawings illustrate embodiments
and together with the description serve to explain principles of
embodiments. Other embodiments and many of the intended advantages
of embodiments will be readily appreciated, as they become better
understood by reference to the following detailed description. The
elements of the drawings are not necessarily to scale relative to
each other. Like reference numerals designate corresponding similar
parts.
[0006] FIG. 1 is a diagram illustrating a computing device suitable
for performing statically type-checked operations on lazily-ordered
datasets according to one embodiment.
[0007] FIG. 2 is a diagrammatic view of a statically type-checked
operations on lazily ordered datasets application for operation on
the computing device illustrated in FIG. 1 according to one
embodiment.
[0008] FIG. 3 is a flow diagram illustrating a method for providing
access to a dataset in a type-safe manner.
[0009] FIG. 4 is a block diagram illustrating a system for
operating on a dataset in a type-safe manner according to one
embodiment.
[0010] FIG. 5 is a diagram illustrating a method for implementing
an operation on a dataset in a key polymorphic form according to
one embodiment.
DETAILED DESCRIPTION
[0011] In the following Detailed Description, reference is made to
the accompanying drawings, which form a part hereof, and in which
is shown by way of illustration specific embodiments in which the
invention may be practiced. It is to be understood that other
embodiments may be utilized and structural or logical changes may
be made without departing from the scope of the present invention.
The following detailed description, therefore, is not to be taken
in a limiting sense, and the scope of the present invention is
defined by the appended claims.
[0012] One embodiment provides an application that performs
statically type-checked operations on lazily ordered datasets, but
the technologies and techniques described herein also serve other
purposes in addition to these. In one implementation, one or more
of the techniques described herein can be implemented as features
within a framework program such as MICROSOFT.RTM. .NET
Framework.
[0013] An ordered dataset is a data structure that stores a
collection of data elements, as well as information that records
their order. For example, to store the ordered dataset (5,3,5), the
elements {3,5,5} are recorded, as well as the fact that the three
is ordered between the two fives. A common way to store the
ordering information in a dataset is to encode the ordering into
the structure of the data representation, which is referred to
herein as a "physically ordered dataset."
[0014] An example of a physically ordered dataset is an array whose
elements are stored in computer memory in the desired order.
Elements of an array are understood to be ordered based on their
ordering in memory. As another example, elements of a singly-linked
list data structure can be understood to be ordered based on the
order in which they would be accessed during a forward traversal
over the linked list.
[0015] In contrast to a physically ordered dataset, a "lazily
ordered dataset", as used herein, may not have its elements
structurally arranged in the element order. Rather, ordering
information is stored explicitly, in addition to the elements.
Typically, for each element, the lazily ordered data set also
stores an associated order key. Ordering of the order keys
determines the ordering of their associated elements. For example,
if the order key for element A comes before the order key for
element B, then element A comes before element B in the element
order.
[0016] Datasets are typically processed by sequence operations. A
sequence operation takes a dataset as an input and produces another
dataset as an output. The sequence operation may change the order
keys, change the elements, or change both the order keys and the
elements. For example, some sequence operations sort the dataset
based on some key, filter out some of the elements, or project each
element.
[0017] Operations on lazily ordered datasets have several
advantages over operations on physically ordered datasets. Some
operations compose more efficiently when working on lazily ordered
datasets than when working on physically ordered datasets. For
example, consider a Sort operation (which sorts a dataset on some
key) followed by a First operation (which returns the first element
according to the order). If implemented using lazy ordering, the
Sort operation will simply associate order keys with elements, but
perform no further work, and the First operation will scan the
dataset and find an element with the lowest order key. However, for
a physically ordered dataset, Sort would fully sort the entire
input, and the time complexity would be increased. Similarly, if a
lazily-ordered dataset is sorted multiple times, only the last sort
will take place.
[0018] Another advantage of lazily-ordered datasets is that they
work well in data-parallel programming. In a data-parallel
scenario, different computing threads are operating on different
partitions of the input data. If threads sort the data at some
intermediate stage of the computation, it is often beneficial to do
it lazily. Otherwise, in order to do an eager sort, all threads
would have to wait on each other, which is a costly operation.
Although lazily-ordered datasets have advantages, as discussed
above, providing a type-safe implementation of these datasets and
operations on them is a challenging task.
[0019] FIG. 1 is a diagram illustrating a computing device 100
suitable for performing statically type-checked operations on
lazily-ordered datasets according to one embodiment. In the
illustrated embodiment, the computing system or computing device
100 includes a plurality of processing units (i.e., processors or
threads) 102 and system memory 104. Depending on the exact
configuration and type of computing device, memory 104 may be
volatile (such as RAM), non-volatile (such as ROM, flash memory,
etc.), or some combination of the two.
[0020] Computing device 100 may also have additional
features/functionality. For example, computing device 100 may also
include additional storage (removable and/or non-removable)
including, but not limited to, magnetic or optical disks or tape.
Such additional storage is illustrated in FIG. 1 by removable
storage 108 and non-removable storage 110. Computer storage media
includes volatile and nonvolatile, removable and non-removable
media implemented in any suitable method or technology for storage
of information such as computer readable instructions, data
structures, program modules or other data. Memory 104, removable
storage 108 and non-removable storage 110 are all examples of
computer storage media. Computer storage media includes, but is not
limited to, RAM, ROM, EEPROM, flash memory or other memory
technology, CD-ROM, digital versatile disks (DVD) or other optical
storage, magnetic cassettes, magnetic tape, magnetic disk storage
or other magnetic storage devices, or any other medium that can be
used to store the desired information and that can be accessed by
computing device 100. Any such computer storage media may be part
of computing device 100.
[0021] Computing device 100 includes one or more communication
connections 114 that allow computing device 100 to communicate with
other computers/applications 115. Computing device 100 may also
include input device(s) 112, such as keyboard, pointing device
(e.g., mouse), pen, voice input device, touch input device, etc.
Computing device 100 may also include output device(s) 111, such as
a display, speakers, printer, etc.
[0022] In one embodiment, computing device 100 includes statically
type-checked operations on lazily ordered datasets application 200.
Statically type-checked operations on lazily ordered datasets
application 200 is described in further detail below with reference
to FIG. 2.
[0023] FIG. 2 is a diagrammatic view of a statically type-checked
operations on lazily ordered datasets application 200 for operation
on the computing device 100 illustrated in FIG. 1 according to one
embodiment. Application 200 is one of the application programs that
reside on computing device 100. However, application 200 can
alternatively or additionally be embodied as computer-executable
instructions on one or more computers and/or in different
variations than illustrated in FIG. 1. Alternatively or
additionally, one or more parts of application 200 can be part of
system memory 104, on other computers and/or applications 115, or
other such suitable variations as would occur to one in the
computer software art.
[0024] Statically type-checked operations on lazily ordered
datasets application 200 includes program logic 202, which is
responsible for carrying out some or all of the techniques
described herein. Program logic 202 includes logic 204 for storing
a lazily-ordered dataset that includes a plurality of data elements
and a corresponding plurality of order keys for indicating an
ordering of the data elements; logic 206 for generating an
interface to the dataset that is implemented as a first generic
class, that is parameterized by an element type parameter and a key
type parameter, and that is configured to provide access to the
data elements and the order keys in the dataset in a type-safe
manner; logic 208 for performing an operation that is configured to
operate on the dataset via the interface and access the data
elements and the order keys in a type-safe manner, wherein the
operation is configured to be statically checked by a compiler to
verify that accesses to the dataset by the operation are type-safe;
logic 210 for statically type-checking an operation at compile-time
to verify that accesses to the dataset by the operation are
type-safe; logic 212 for performing an operation configured to
generate a generic action object and pass the generic action object
to a second generic class that is parameterized solely by an
element type parameter, wherein the first generic class inherits
from the second generic class; logic 214 for forwarding the generic
action object from the second generic class to the first generic
class; logic 216 for executing the generic action object with the
first generic class, thereby executing the generic action object in
a context in which types of the order keys are statically
available; and other logic 218 for operating the application.
[0025] Turning now to FIGS. 3-5, techniques for implementing one or
more embodiments of statically type-checked operations on lazily
ordered datasets application 200 are described in further detail.
In some implementations, the techniques illustrated in FIGS. 3-5
are at least partially implemented in the operating logic of
computing device 100.
[0026] FIG. 3 is a flow diagram illustrating a method 300 for
providing access to a dataset in a type-safe manner. At 302, a
dataset is stored that includes a plurality of data elements and a
corresponding plurality of order keys for indicating an ordering of
the data elements, wherein each order key is associated with one of
the data elements. Since the dataset stored at 302 includes order
keys associated with the data elements, the dataset is referred to
herein as a lazily-ordered dataset. At 304, an interface to the
dataset is generated that is parameterized by an element type
parameter and a key type parameter, wherein the interface is
configured to provide access to the data elements and the order
keys in the dataset in a type-safe manner.
[0027] At 306, an operation is performed that is configured to
operate on the dataset via the interface, wherein the operation is
configured to be statically checked by a compiler to verify that
accesses to the dataset by the operation are type-safe. In one
embodiment, the operation performed at 306 is configured to be
statically verified at compile time to satisfy type safety
constraints, and is configured to access the data elements and the
order keys in a type-safe manner. In one embodiment, multiple
operations are performed at 306, and the operations are statically
or dynamically composed.
[0028] FIG. 4 is a block diagram illustrating a system 400 for
operating on a dataset in a type-safe manner according to one
embodiment. System 400 includes operation 402, interface 408, and
dataset 414. Operation 402 is parameterized by parameters 404 and
406. In the illustrated embodiment, parameter 404 is an element
type parameter, and parameter 406 is a key type parameter.
Interface 408 is parameterized by parameters 410 and 412. In the
illustrated embodiment, parameter 410 is an element type parameter,
and parameter 412 is a key type parameter. Dataset 414 includes a
plurality of data elements 416 and a corresponding plurality of
order keys 418 for indicating an ordering of the data elements 416,
wherein each order key is associated with one of the data
elements.
[0029] Since the dataset 414 includes order keys 418 associated
with the data elements 416, the dataset 414 is referred to herein
as a lazily-ordered dataset. The interface 408 is configured to
provide access to the data elements 416 and the order keys 418 in
the dataset 414 in a type-safe manner for one or more operations,
such as operation 402. Operation 402 is configured to operate on
the dataset 414 via the interface 408. In one embodiment, the
operation 402 is configured to be statically checked by a compiler
to verify that accesses to the dataset 414 by the operation 402 are
type-safe.
[0030] In one embodiment, interface 408 is implemented as a generic
class as shown in the following Pseudo Code Example I:
TABLE-US-00001 PSEUDO CODE EXAMPLE I class DataSet<TElement,
TKey> { public IEnumerator<Pair<TElement, TKey>>
GetContents( ) {...} public IComparer<TKey> GetComparer( )
{...} }
[0031] A generic class, such as that given in Example I above, is
parameterized by the types of data that the class stores and
manipulates. The generic type parameters are specified between
angle brackets, < >, after the class name. The generic type
parameters act as placeholders until an actual type is specified at
use. Instances of the class accept the type for which they are
created and store data of that type without conversion. Generics
allow type-safe data structures to be defined without committing to
actual data types. In the .NET framework, the compiled
representation of a generic type is intermediate language (IL)
instructions and metadata. The compiled representation of the
generic type encodes the existence and use of type parameters. The
first time that an application creates an instance of a constructed
generic type, the just-in-time (JIT) compiler of the .NET Common
Language Runtime (CLR) converts the generic IL and metadata to
native code, substituting actual types for type parameters in the
process. Subsequent references to that constructed generic type
then use the same native code. The process of creating a specific
constructed type from a generic type is known as generic type
instantiation.
[0032] As shown in Example I, the generic class implementation of
interface 408 is parameterized by the generic type parameters
TElement and TKey, which correspond to the element type parameter
410 and the key type parameter 412, respectively. A generic class,
such as that given in Example I, may include one or more generic
methods that each include one or more generic type parameters
specified in angle brackets, < >, following the method name.
When calling a generic method, type arguments are given in angle
brackets in the method invocation. As shown in Example I, the
interface 408 includes a generic GetContents( ) enumerator method
(parameterized by a generic element type parameter and a generic
key type parameter), which returns an enumerator over element/key
pairs. By iterating over the returned enumerator, the user of this
class can access all elements 416 in the dataset 414, together with
their order keys 418. The generic GetComparer( ) method in Example
I is parameterized by a generic key type parameter and returns a
class that can compare any two order keys and decide whether they
differ, and if they do, identify which key is smaller in value.
[0033] In one embodiment, operations on datasets, such as operation
402, are implemented as shown in the following Pseudo Code Example
II:
TABLE-US-00002 PSEUDO CODE EXAMPLE II public static
DataSet<TOutputElement, TOutputKey>
Operation<TInputElement, TInputKey, TOutputElement,
TOutputKey>( DataSet<TInputElement, TInputKey> input) {
... }
[0034] An operation, such as operation 402, can change the ordering
of elements 416, change the values of elements 416, add elements
416, and remove elements 416 in dataset 414. The body of operation
402 can be statically checked by a compiler to ensure that all
accesses to elements 416 and order keys 418 in dataset 414 are
type-safe.
[0035] The general form of an operation given in Pseudo Code
Example II may vary depending on the type of the operation. For
example, a Sort operation, according to one embodiment, which sorts
elements based on their values, is implemented as shown in the
following Pseudo Code Example III:
TABLE-US-00003 PSEUDO CODE EXAMPLE III public static
DataSet<TInputElement, TInputElement> Sort<TInputElement,
TInputKey>( DataSet<TInputElement, TInputKey> input) { ...
create and return a dataset that contains the same elements as the
input data set, but each element is also its own order key ...
}
[0036] As another example, a Map operation, according to one
embodiment, which creates a new dataset by applying a function to
each element in the input, and constructs a dataset out of the
outputs, is implemented as shown in the following Pseudo Code
Example IV:
TABLE-US-00004 PSEUDO CODE EXAMPLE IV public static
DataSet<TOutputElement, TInputKey> Map<TInputElement,
TInputKey, TOutputElement>( DataSet<TInputElement,
TInputKey> input, Func<TInputElement, TOutputElement> F) {
... if the dataset is e.sub.1, e.sub.2, .. e.sub.n, return the
output dataset F(e.sub.1), F(e.sub.2), ... F(e.sub.n). The output
dataset should be in the same order as the input dataset ... }
[0037] In many cases, it is useful to be able to abstract away the
key type, and operate on the dataset 414 based only on element
type. In one embodiment, the generic class, DataSet<TElement,
TKey>, in Pseudo Code Example I, inherits from a second generic
class DataSetBase<TElement>, which is parameterized solely by
a generic element type parameter, and which is referred to herein
as a dataset in a "key-polymorphic" form. Inheritance allows
classes to easily share common features. A child class (also known
as a derived class) inherits the properties of its parent (base)
class, and is free to add features of its own. This allows classes
to share common features.
[0038] In one embodiment, a lazily-ordered dataset is passed around
in the key-polymorphic form, DataSetBase<TElement>, rather
than in the original form, DataSet<TElement,TKey>. The
signature of the Sort operation given in Pseudo Code Example III is
simpler when applied to a dataset in the key-polymorphic form, as
shown in the following Pseudo Code Example V:
TABLE-US-00005 PSEUDO CODE EXAMPLE V public static
DataSet<TInputElement, TInputElement> Sort<TInputElement
>( DataSetBase<TInputElement>input)
[0039] Manipulating lazily-ordered datasets in the key-polymorphic
form allows implementation of operations that can dynamically
decide the type of the order key. For example, consider the
OptionalSort operation given in the following Pseudo Code Example
VI:
TABLE-US-00006 PSEUDO CODE EXAMPLE VI public static
DataSetBase<TInputElement> OptionalSort<TInputElement>(
DataSetBase<TInputElement> source, bool performSort)
[0040] The OptionalSort operation given in Example VI decides
whether to sort elements in a dataset based on the value of the
"performSort" flag. If the flag is true, the OptionalSort operation
changes the order keys of elements in the dataset. If the flag is
false, the original keys will remain. By returning the dataset in
the key-polymorphic form, the type of the order keys can be
abstracted away, and OptionalSort can decide what that key type
will be dynamically.
[0041] One issue that arises when order keys have been abstracted
away is how to regain access to the order keys on a dataset in the
key-polymorphic form. For example, given a reference to
DataSetBase<TInputElement>, an issue that arises is how can
some code be executed that can access both elements and keys, and
have that code be statically type-checked. For example, assume that
a First operation is implemented with a signature as shown in the
following Pseudo Code Example VII:
TABLE-US-00007 PSEUDO CODE EXAMPLE VII public static TInputElement
First<TInputElement>( DataSetBase<TInputElement>
source)
[0042] An issue that arises with respect to the First operation
given in Example VII is that the operation does not have access to
the TKey type. Without the TKey type, the operation is not able to
manipulate keys in the source dataset in a type-safe fashion. One
solution to this issue according to one embodiment is to use a
generic callback mechanism. The generic callback mechanism
according to one embodiment takes a dataset in the key-polymorphic
form, and executes an operation on it in a context where it has
access to the type of the order keys. In one embodiment of the
generic callback mechanism, an object is constructed that
represents an action that is to be executed in a context with
access to the TKey type. A generic action is passed to the
DataSetBase<TInputElement> object, which then forwards it to
the concrete DataSet<TInputElement, TKey> implementation,
which will finally execute the action in a context with access to
the TKey type.
[0043] For example, given DataSetBase<TElement>, an operation
First<TElement> can be implemented that finds the element in
the dataset with the smallest key, and executes in a context where
it can refer to the TKey type statically. FIG. 5 is a diagram
illustrating a method 500 for implementing a First operation on a
dataset in a key polymorphic form according to one embodiment. The
method 500 begins with a First<TInputElement> operation 502.
As indicated at 504, the First<TInputElement> operation 502
constructs a Generic Action object 506. As indicated at 508, the
First<TInputElement> operation 502 passes the Generic Action
object to DataSetBase<TInputElement> 512. As indicated at
514, the DataSetBase<TInputElement> 512 forwards the Generic
Action object 506 to its derived class, DataSet<TInputElement,
TKey> 516, via a virtual method call. As indicated at 510,
DataSet<TInputElement, TKey> 516 invokes a perform method,
GenericAction.Perform<TKey>( ) 507, to execute the generic
action object. Consequently, the generic action executes in a
context in which the types of the order keys are statically
available.
[0044] Although specific embodiments have been illustrated and
described herein, it will be appreciated by those of ordinary skill
in the art that a variety of alternate and/or equivalent
implementations may be substituted for the specific embodiments
shown and described without departing from the scope of the present
invention. This application is intended to cover any adaptations or
variations of the specific embodiments discussed herein. Therefore,
it is intended that this invention be limited only by the claims
and the equivalents thereof.
* * * * *