From d593b2f210b5cf3f465b57cdc0bffba7203eb049 Mon Sep 17 00:00:00 2001 From: Simon Nattress Date: Wed, 15 Jun 2016 12:40:01 -0700 Subject: Fix a couple typos in type system document --- Documentation/botr/type-system.md | 6 +++--- Documentation/images/typesystem-hierarchy.png | Bin 26536 -> 27524 bytes Documentation/images/typesystem-hierarchy.svg | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') 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 Binary files a/Documentation/images/typesystem-hierarchy.png and b/Documentation/images/typesystem-hierarchy.png 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" /> ParametrizedType + sodipodi:role="line">ParameterizedType