зеркало из https://github.com/golang/example.git
gotypes: minor fixes
Change-Id: Ie730f983c12a20c6c50e289650e230a05b1c782b Reviewed-on: https://go-review.googlesource.com/17972 Reviewed-by: Alan Donovan <adonovan@google.com>
This commit is contained in:
Alan Donovan
Alan Donovan
Родитель
637ffe0981
Коммит
bceddce91a
|
|
@ -222,7 +222,7 @@ instance---must have access to the `FileSet`.
|
|||
|
||||
Second, the program parses the input string.
|
||||
More realistic packages contain several source files, so the parsing
|
||||
step must be repeated for each one, or better still, done in parallel.
|
||||
step must be repeated for each one, or better, done in parallel.
|
||||
Third, it creates a `Config` that specifies type-checking options.
|
||||
Since the _hello, world_ program uses imports, we must indicate
|
||||
how to locate the imported packages.
|
||||
|
|
@ -304,11 +304,11 @@ object-oriented programming.)
|
|||
|
||||
|
||||
|
||||
Objects are represented by the `Object` interface, shown below:
|
||||
Objects are represented by the `Object` interface:
|
||||
|
||||
|
||||
type Object interface {
|
||||
Name() string // package local object name
|
||||
Name() string // package-local object name
|
||||
Exported() bool // reports whether the name starts with a capital letter
|
||||
Type() Type // object type
|
||||
Pos() token.Pos // position of object identifier in declaration
|
||||
|
|
@ -338,7 +338,7 @@ individual fields for the file name, line number, column, and byte
|
|||
offset, though usually we just call its `String` method:
|
||||
|
||||
|
||||
fmt.Fprintln(fset.Position(obj.Pos())) // "hello.go:10:6"
|
||||
fmt.Println(fset.Position(obj.Pos())) // "hello.go:10:6"
|
||||
|
||||
|
||||
Not all objects carry position information.
|
||||
|
|
@ -349,7 +349,7 @@ imported from such a file returns zero, also known as
|
|||
|
||||
|
||||
|
||||
There are eight kinds of objects in the Go type checker.
|
||||
There are eight kinds of object in the Go type checker.
|
||||
Most familiar are the kinds that can be declared at package level:
|
||||
constants, variables, functions, and types.
|
||||
Less familiar are statement labels, imported package names
|
||||
|
|
@ -388,6 +388,7 @@ which the object was declared; we'll come back to this in
|
|||
[Scopes](#scopes).
|
||||
Fields and methods are not found in the lexical environment, so
|
||||
their objects have no `Parent`.
|
||||
<!-- TODO check this -->
|
||||
|
||||
|
||||
|
||||
|
|
@ -702,8 +703,8 @@ The structure of the lexical environment thus forms a tree, with the
|
|||
universe block at the root, the package blocks beneath it, the file
|
||||
blocks beneath them, and then any number of local blocks beneath the
|
||||
files.
|
||||
The following methods of `Scope` make this tree structure
|
||||
accessible and navigable:
|
||||
We can access and navigate this tree structure with the following
|
||||
methods of `Scope`:
|
||||
|
||||
|
||||
func (s *Scope) Parent() *Scope
|
||||
|
|
@ -768,7 +769,7 @@ before or after that point.
|
|||
|
||||
|
||||
`Pos` and `End` report the `Scope`'s start and end
|
||||
position which, for explicit blocks, are coincident with its curly
|
||||
position which, for explicit blocks, coincide with its curly
|
||||
braces.
|
||||
`Contains` is a convenience method that reports whether a
|
||||
position lies in this interval.
|
||||
|
|
@ -898,6 +899,7 @@ each level of the tree of lexical blocks.
|
|||
PkgName ✔
|
||||
Label ✔
|
||||
|
||||
|
||||
# Initialization Order
|
||||
|
||||
|
||||
|
|
@ -951,7 +953,8 @@ Across packages, dependencies must be initialized first, although the
|
|||
order among them is not specified.
|
||||
That is, any topological order of the import graph will do.
|
||||
The `(*Package).Imports` method returns the set of direct
|
||||
dependencies of a package, in an unspecified order.
|
||||
dependencies of a package.
|
||||
>>>>>>> 637ffe0981073879a95f848fd9528efe9231bed9
|
||||
|
||||
|
||||
# Types
|
||||
|
|
@ -1066,7 +1069,7 @@ for expressions containing errors, or for objects without types, like
|
|||
The `Name` method returns the name of the type, such as
|
||||
`"float64"`, and the `Info` method returns a bitfield that
|
||||
encodes information about the type, such as whether it is signed or
|
||||
unsigned, integer or floating point, real or complex.
|
||||
unsigned, integer or floating point, or real or complex.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1135,6 +1138,7 @@ ordered list of field tags.
|
|||
Each field is a `Var` object whose `IsField` method returns true.
|
||||
Field objects have no `Parent` scope, because they are
|
||||
resolved through selections, not through the lexical environment.
|
||||
<!-- TODO check this -->
|
||||
|
||||
|
||||
|
||||
|
|
@ -1172,7 +1176,7 @@ and to `U`, and short of inspecting source positions or walking
|
|||
the AST---neither of which is possible for objects loaded from compiler
|
||||
export data---it is not possible to ascertain that `x` was declared as
|
||||
part of `T`.
|
||||
The type checker computes the exact same data structures given this input:
|
||||
The type checker builds the exact same data structures given this input:
|
||||
|
||||
|
||||
type T U
|
||||
|
|
@ -1264,7 +1268,7 @@ These types are recorded during type checking for later use
|
|||
A type declaration creates a `TypeName` object, and the type of
|
||||
that object is a `Named`.
|
||||
These two entities, an object and a type, are distinct but closely
|
||||
related, and they exist in one-to-one correpondence.
|
||||
related, and they exist in one-to-one correspondence.
|
||||
|
||||
|
||||
type Named struct{ ... }
|
||||
|
|
@ -1405,15 +1409,15 @@ of the `Info` struct, namely `Types`:
|
|||
}
|
||||
|
||||
|
||||
No entry is recorded for identifiers since the `Defs` and
|
||||
No entries are recorded for identifiers since the `Defs` and
|
||||
`Uses` maps provide more information about them.
|
||||
Also, no entry is recorded for pseudo-expressions like
|
||||
Also, no entries are recorded for pseudo-expressions like
|
||||
`*ast.KeyValuePair` or `*ast.Ellipsis`.
|
||||
|
||||
|
||||
|
||||
The value of the `Types` map is a `TypeAndValue`, which
|
||||
(unsurprisingly) holds the `Type` and value of the expression, and in
|
||||
(unsurprisingly) holds the type and value of the expression, and in
|
||||
addition, its _mode_.
|
||||
The mode is opaque, but has predicates to answer questions such as:
|
||||
Does this expression denote a value or a type? Does this value have an
|
||||
|
|
@ -1437,7 +1441,7 @@ satisfy each predicate.
|
|||
func (TypeAndValue) IsNil() bool // e.g. "nil"
|
||||
func (TypeAndValue) Addressable() bool // e.g. "a[i]" but not "f()", "m[key]"
|
||||
func (TypeAndValue) Assignable() bool // e.g. "a[i]", "m[key]"
|
||||
func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
|
||||
func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
|
||||
|
||||
|
||||
The statement below inspects every expression within the AST of a single
|
||||
|
|
@ -1707,12 +1711,9 @@ and `Indirect`.
|
|||
|
||||
The `addressable` flag should be set if the receiver is a
|
||||
_variable_ of type `T`, since in a method selection on a
|
||||
variable, an implicit address-of operation (`&`) may occur.
|
||||
variable, an implicit address-of operation (`&`) may occur.
|
||||
The flag indicates whether the methods of type `*T` should be
|
||||
considered during the lookup.
|
||||
|
||||
|
||||
|
||||
(You may wonder why this parameter is necessary. Couldn't clients
|
||||
instead call `LookupFieldOrMethod` on the pointer type `*T`
|
||||
if the receiver is a `T` variable? The answer is that if
|
||||
|
|
@ -1826,7 +1827,7 @@ Clients can request the method set of a type `T` by calling
|
|||
func (s *MethodSet) Lookup(pkg *Package, name string) *Selection
|
||||
|
||||
|
||||
The `Len` and `At` methods access a a list of
|
||||
The `Len` and `At` methods access a list of
|
||||
`Selections`, all of kind `MethodVal`, ordered by `Id`.
|
||||
The `Lookup` function allows lookup of a single method by
|
||||
name (and package path, as explained in the previous section).
|
||||
|
|
@ -2087,7 +2088,7 @@ and for constructing new values:
|
|||
|
||||
|
||||
All numeric `Value`s, whether integer or floating-point, signed or
|
||||
unsigned, or real or complex, are represented more precisely than the
|
||||
unsigned, or real or complex, are represented more precisely than
|
||||
ordinary Go types like `int64` and `float64`.
|
||||
Internally, the `go/constant` package uses multi-precision data types
|
||||
like `Int`, `Rat`, and `Float` from the `math/big` package so that
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ instance---must have access to the `FileSet`.
|
|||
|
||||
Second, the program parses the input string.
|
||||
More realistic packages contain several source files, so the parsing
|
||||
step must be repeated for each one, or better still, done in parallel.
|
||||
step must be repeated for each one, or better, done in parallel.
|
||||
Third, it creates a `Config` that specifies type-checking options.
|
||||
Since the _hello, world_ program uses imports, we must indicate
|
||||
how to locate the imported packages.
|
||||
|
|
@ -221,11 +221,11 @@ object-oriented programming.)
|
|||
|
||||
|
||||
|
||||
Objects are represented by the `Object` interface, shown below:
|
||||
Objects are represented by the `Object` interface:
|
||||
|
||||
|
||||
type Object interface {
|
||||
Name() string // package local object name
|
||||
Name() string // package-local object name
|
||||
Exported() bool // reports whether the name starts with a capital letter
|
||||
Type() Type // object type
|
||||
Pos() token.Pos // position of object identifier in declaration
|
||||
|
|
@ -255,7 +255,7 @@ individual fields for the file name, line number, column, and byte
|
|||
offset, though usually we just call its `String` method:
|
||||
|
||||
|
||||
fmt.Fprintln(fset.Position(obj.Pos())) // "hello.go:10:6"
|
||||
fmt.Println(fset.Position(obj.Pos())) // "hello.go:10:6"
|
||||
|
||||
|
||||
Not all objects carry position information.
|
||||
|
|
@ -266,7 +266,7 @@ imported from such a file returns zero, also known as
|
|||
|
||||
|
||||
|
||||
There are eight kinds of objects in the Go type checker.
|
||||
There are eight kinds of object in the Go type checker.
|
||||
Most familiar are the kinds that can be declared at package level:
|
||||
constants, variables, functions, and types.
|
||||
Less familiar are statement labels, imported package names
|
||||
|
|
@ -305,6 +305,7 @@ which the object was declared; we'll come back to this in
|
|||
[Scopes](#scopes).
|
||||
Fields and methods are not found in the lexical environment, so
|
||||
their objects have no `Parent`.
|
||||
<!-- TODO check this -->
|
||||
|
||||
|
||||
|
||||
|
|
@ -578,8 +579,8 @@ The structure of the lexical environment thus forms a tree, with the
|
|||
universe block at the root, the package blocks beneath it, the file
|
||||
blocks beneath them, and then any number of local blocks beneath the
|
||||
files.
|
||||
The following methods of `Scope` make this tree structure
|
||||
accessible and navigable:
|
||||
We can access and navigate this tree structure with the following
|
||||
methods of `Scope`:
|
||||
|
||||
|
||||
func (s *Scope) Parent() *Scope
|
||||
|
|
@ -644,7 +645,7 @@ before or after that point.
|
|||
|
||||
|
||||
`Pos` and `End` report the `Scope`'s start and end
|
||||
position which, for explicit blocks, are coincident with its curly
|
||||
position which, for explicit blocks, coincide with its curly
|
||||
braces.
|
||||
`Contains` is a convenience method that reports whether a
|
||||
position lies in this interval.
|
||||
|
|
@ -717,6 +718,7 @@ each level of the tree of lexical blocks.
|
|||
PkgName ✔
|
||||
Label ✔
|
||||
|
||||
|
||||
# Initialization Order
|
||||
|
||||
|
||||
|
|
@ -770,7 +772,8 @@ Across packages, dependencies must be initialized first, although the
|
|||
order among them is not specified.
|
||||
That is, any topological order of the import graph will do.
|
||||
The `(*Package).Imports` method returns the set of direct
|
||||
dependencies of a package, in an unspecified order.
|
||||
dependencies of a package.
|
||||
>>>>>>> 637ffe0981073879a95f848fd9528efe9231bed9
|
||||
|
||||
|
||||
# Types
|
||||
|
|
@ -885,7 +888,7 @@ for expressions containing errors, or for objects without types, like
|
|||
The `Name` method returns the name of the type, such as
|
||||
`"float64"`, and the `Info` method returns a bitfield that
|
||||
encodes information about the type, such as whether it is signed or
|
||||
unsigned, integer or floating point, real or complex.
|
||||
unsigned, integer or floating point, or real or complex.
|
||||
|
||||
|
||||
|
||||
|
|
@ -954,6 +957,7 @@ ordered list of field tags.
|
|||
Each field is a `Var` object whose `IsField` method returns true.
|
||||
Field objects have no `Parent` scope, because they are
|
||||
resolved through selections, not through the lexical environment.
|
||||
<!-- TODO check this -->
|
||||
|
||||
|
||||
|
||||
|
|
@ -991,7 +995,7 @@ and to `U`, and short of inspecting source positions or walking
|
|||
the AST---neither of which is possible for objects loaded from compiler
|
||||
export data---it is not possible to ascertain that `x` was declared as
|
||||
part of `T`.
|
||||
The type checker computes the exact same data structures given this input:
|
||||
The type checker builds the exact same data structures given this input:
|
||||
|
||||
|
||||
type T U
|
||||
|
|
@ -1083,7 +1087,7 @@ These types are recorded during type checking for later use
|
|||
A type declaration creates a `TypeName` object, and the type of
|
||||
that object is a `Named`.
|
||||
These two entities, an object and a type, are distinct but closely
|
||||
related, and they exist in one-to-one correpondence.
|
||||
related, and they exist in one-to-one correspondence.
|
||||
|
||||
|
||||
type Named struct{ ... }
|
||||
|
|
@ -1224,15 +1228,15 @@ of the `Info` struct, namely `Types`:
|
|||
}
|
||||
|
||||
|
||||
No entry is recorded for identifiers since the `Defs` and
|
||||
No entries are recorded for identifiers since the `Defs` and
|
||||
`Uses` maps provide more information about them.
|
||||
Also, no entry is recorded for pseudo-expressions like
|
||||
Also, no entries are recorded for pseudo-expressions like
|
||||
`*ast.KeyValuePair` or `*ast.Ellipsis`.
|
||||
|
||||
|
||||
|
||||
The value of the `Types` map is a `TypeAndValue`, which
|
||||
(unsurprisingly) holds the `Type` and value of the expression, and in
|
||||
(unsurprisingly) holds the type and value of the expression, and in
|
||||
addition, its _mode_.
|
||||
The mode is opaque, but has predicates to answer questions such as:
|
||||
Does this expression denote a value or a type? Does this value have an
|
||||
|
|
@ -1256,7 +1260,7 @@ satisfy each predicate.
|
|||
func (TypeAndValue) IsNil() bool // e.g. "nil"
|
||||
func (TypeAndValue) Addressable() bool // e.g. "a[i]" but not "f()", "m[key]"
|
||||
func (TypeAndValue) Assignable() bool // e.g. "a[i]", "m[key]"
|
||||
func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
|
||||
func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
|
||||
|
||||
|
||||
The statement below inspects every expression within the AST of a single
|
||||
|
|
@ -1408,12 +1412,9 @@ and `Indirect`.
|
|||
|
||||
The `addressable` flag should be set if the receiver is a
|
||||
_variable_ of type `T`, since in a method selection on a
|
||||
variable, an implicit address-of operation (`&`) may occur.
|
||||
variable, an implicit address-of operation (`&`) may occur.
|
||||
The flag indicates whether the methods of type `*T` should be
|
||||
considered during the lookup.
|
||||
|
||||
|
||||
|
||||
(You may wonder why this parameter is necessary. Couldn't clients
|
||||
instead call `LookupFieldOrMethod` on the pointer type `*T`
|
||||
if the receiver is a `T` variable? The answer is that if
|
||||
|
|
@ -1527,7 +1528,7 @@ Clients can request the method set of a type `T` by calling
|
|||
func (s *MethodSet) Lookup(pkg *Package, name string) *Selection
|
||||
|
||||
|
||||
The `Len` and `At` methods access a a list of
|
||||
The `Len` and `At` methods access a list of
|
||||
`Selections`, all of kind `MethodVal`, ordered by `Id`.
|
||||
The `Lookup` function allows lookup of a single method by
|
||||
name (and package path, as explained in the previous section).
|
||||
|
|
@ -1687,7 +1688,7 @@ and for constructing new values:
|
|||
|
||||
|
||||
All numeric `Value`s, whether integer or floating-point, signed or
|
||||
unsigned, or real or complex, are represented more precisely than the
|
||||
unsigned, or real or complex, are represented more precisely than
|
||||
ordinary Go types like `int64` and `float64`.
|
||||
Internally, the `go/constant` package uses multi-precision data types
|
||||
like `Int`, `Rat`, and `Float` from the `math/big` package so that
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче