Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/corert.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Nattress <nattress@gmail.com>2016-06-15 22:40:01 +0300
committerSimon Nattress <nattress@gmail.com>2016-06-17 01:26:19 +0300
commitd593b2f210b5cf3f465b57cdc0bffba7203eb049 (patch)
tree140faf5854191f26155e74b6da9170556dac4350 /Documentation
parentabb3716a94b9e6695c414b1e9ed7d9b54839ceaf (diff)
Fix a couple typos in type system document
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/botr/type-system.md6
-rw-r--r--Documentation/images/typesystem-hierarchy.pngbin26536 -> 27524 bytes
-rw-r--r--Documentation/images/typesystem-hierarchy.svg4
3 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/botr/type-system.md b/Documentation/botr/type-system.md
index 63d84543d..eee73ff98 100644
--- a/Documentation/botr/type-system.md
+++ b/Documentation/botr/type-system.md
@@ -25,7 +25,7 @@ Low overhead is achieved by lazy loading - instead of eagerly populating the typ
Where necessary, partial classes, extension methods, and pluggable algorithms are used to achieve goal 3 instead of polymorphism and object hierarchies. The reusability of the type system is at the source level (source-including different sets of files to get different features). This allows extensibility without making sacrifices that would take us away from goal 1.
-The type system in its purest form (i.e. without any partial class extensions) tries to avoid introducing concepts that are not defined in the [ECMA-335 specification](http://www.ecma-international.org/publications/standards/Ecma-335.htm). The specification is a suggested pre-requisite reading to this document and provides definitions to various terms used in this document.
+The type system in its purest form (i.e. without any partial class extensions) tries to avoid introducing concepts that are not defined in the [ECMA-335 specification](http://www.ecma-international.org/publications/standards/Ecma-335.htm). The specification is a suggested prerequisite reading to this document and provides definitions to various terms used in this document.
## Relationship with metadata
@@ -51,7 +51,7 @@ Following section goes briefly over the classes representing types within the ty
`TypeDesc` is the base class of all types within the type system. It defines a list of operations all classes must support. Not all operations might make sense for all the children of `TypeDesc` (for example, it doesn't make sense to request a list of methods on a pointer type), but care is taken to provide an implementation that makes sense for each particular child (i.e. the list of methods on a pointer type is empty).
-### ParametrizedType (ArrayType, ByRefType, PointerType)
+### ParameterizedType (ArrayType, ByRefType, PointerType)
These are constructed types with a single parameter:
@@ -63,7 +63,7 @@ Note the distinction between multidimensional arrays of rank 1 and vectors is a
### DefType (NoMetadataType, MetadataType)
-`DefType` represents a value type, interface, or a class. While most instances of `DefType` will be of children of `MetadataType` (a type that is based off of some concrete metadata describing the type in full), there will be scenarios where full metadata is no longer available. In those cases, only restricted information (such as the number of bytes occupied by the instance of the type on the GC heap, or whether the type is a value type) is available. It is important that the type system is able to operate on such types. E.g. it should be possible for a type with restricted metadata to be a base type for a type with full metadata and the field layout algorithm should be able to compute the field layout of such type.
+`DefType` represents a value type, interface, or a class. While most instances of `DefType` will be of children of `MetadataType` (a type that is based off of some concrete metadata describing the type in full), there will be scenarios where full metadata is no longer available. In those cases, only restricted information (such as the number of bytes occupied by the instance of the type on the GC heap, or whether the type is a value type) is available. It is important that the type system is able to operate on such types. E.g. it should be possible for a type with restricted metadata to be a base type for a type with full metadata and the field layout algorithm should be able to compute the field layout of such a type.
### GenericParameter
diff --git a/Documentation/images/typesystem-hierarchy.png b/Documentation/images/typesystem-hierarchy.png
index 96e937132..61710f3ca 100644
--- a/Documentation/images/typesystem-hierarchy.png
+++ b/Documentation/images/typesystem-hierarchy.png
Binary files differ
diff --git a/Documentation/images/typesystem-hierarchy.svg b/Documentation/images/typesystem-hierarchy.svg
index 9aee9662c..3609b754b 100644
--- a/Documentation/images/typesystem-hierarchy.svg
+++ b/Documentation/images/typesystem-hierarchy.svg
@@ -113,7 +113,7 @@
y="219.74541"
x="-478.96786"
height="118.04868"
- width="412.33441"
+ width="432.33441"
id="rect3338-1" />
<text
sodipodi:linespacing="125%"
@@ -125,7 +125,7 @@
id="tspan3369"
y="289.94162"
x="-452.25378"
- sodipodi:role="line">ParametrizedType</tspan></text>
+ sodipodi:role="line">ParameterizedType</tspan></text>
</g>
<g
id="g3534"