You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@groovy.apache.org by pa...@apache.org on 2022/10/19 07:52:31 UTC
[groovy] branch master updated: Fix minor typos in documentations in spec/doc
This is an automated email from the ASF dual-hosted git repository.
paulk pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/groovy.git
The following commit(s) were added to refs/heads/master by this push:
new 40da700d52 Fix minor typos in documentations in spec/doc
40da700d52 is described below
commit 40da700d527c67bfb29fc075c6ad500c68c48136
Author: Marc Wrobel <ma...@gmail.com>
AuthorDate: Tue Oct 18 12:36:36 2022 +0200
Fix minor typos in documentations in spec/doc
A few trailing whitespaces were removed in the process.
---
src/spec/doc/_design-pattern-monoid.adoc | 2 +-
src/spec/doc/_design-pattern-singleton.adoc | 4 ++--
src/spec/doc/_records.adoc | 2 +-
src/spec/doc/_traits.adoc | 2 +-
src/spec/doc/_type-checking-extensions.adoc | 2 +-
src/spec/doc/_working-with-io.adoc | 2 +-
src/spec/doc/core-closures.adoc | 8 ++++----
src/spec/doc/core-differences-java.adoc | 2 +-
src/spec/doc/core-domain-specific-languages.adoc | 10 ++++-----
src/spec/doc/core-getting-started.adoc | 4 ++--
src/spec/doc/core-metaprogramming.adoc | 26 ++++++++++++------------
src/spec/doc/core-object-orientation.adoc | 20 +++++++++---------
src/spec/doc/core-operators.adoc | 2 +-
src/spec/doc/core-program-structure.adoc | 12 +++++------
src/spec/doc/core-semantics.adoc | 26 ++++++++++++------------
src/spec/doc/core-syntax.adoc | 8 ++++----
src/spec/doc/core-testing-guide.adoc | 24 +++++++++++-----------
src/spec/doc/grape.adoc | 6 +++---
src/spec/doc/guide-integrating.adoc | 2 +-
src/spec/doc/performance-guide.adoc | 2 +-
src/spec/doc/style-guide.adoc | 6 +++---
src/spec/doc/tools-groovyc.adoc | 6 +++---
22 files changed, 89 insertions(+), 89 deletions(-)
diff --git a/src/spec/doc/_design-pattern-monoid.adoc b/src/spec/doc/_design-pattern-monoid.adoc
index 111b94cec3..a8125e4ce8 100644
--- a/src/spec/doc/_design-pattern-monoid.adoc
+++ b/src/spec/doc/_design-pattern-monoid.adoc
@@ -105,7 +105,7 @@ we can employ some interesting ways to solve the aggregation including:
to potentially start part way through be reusing a cached value of summing 1..4 if that had been calculated earlier
* Inherent parallelization can make use of multiple cores
-Let's just look at the first of these in more detail. With a multi-core
+Let's just look at the first of these in more detail. With a multicore
processor, one core could add `10` plus `11`, another core `12` plus `13`, and so on.
We'd use the _identity_ element if needed (shown being added to `16` in our example).
Then the intermediate results could also be added together concurrently and so on until the result was reached.
diff --git a/src/spec/doc/_design-pattern-singleton.adoc b/src/spec/doc/_design-pattern-singleton.adoc
index dee50276f0..67c422193e 100644
--- a/src/spec/doc/_design-pattern-singleton.adoc
+++ b/src/spec/doc/_design-pattern-singleton.adoc
@@ -38,7 +38,7 @@ Suppose we wish to create a class for collecting votes. Because getting the righ
include::../test/DesignPatternsTest.groovy[tags=singleton_vote_collector,indent=0]
----
-Some points of interest about this code:
+Some points of interest in this code:
- it has a private constructor, so no `VoteCollector` objects can be created in our system (except for the `INSTANCE` we create)
- the `INSTANCE` is also private, so it can't be changed once set
@@ -158,4 +158,4 @@ Client: 14800362, Calc: 10580099, Total Calculations: 2
- http://www.ibm.com/developerworks/webservices/library/co-single/index.html[Use your singletons wisely]
- http://www.ibm.com/developerworks/java/library/j-dcl/index.html[Double-checked locking and the Singleton pattern]
- https://web.archive.org/web/20160807234810/http://blog.crazybob.org/2007/01/lazy-loading-singletons.html[Lazy Loading Singletons]
-- https://csharpindepth.com/Articles/Singleton[Implementing the Singleton Pattern in C#]
\ No newline at end of file
+- https://csharpindepth.com/Articles/Singleton[Implementing the Singleton Pattern in C#]
diff --git a/src/spec/doc/_records.adoc b/src/spec/doc/_records.adoc
index 9aa8ac8a6d..1d507fca06 100644
--- a/src/spec/doc/_records.adoc
+++ b/src/spec/doc/_records.adoc
@@ -58,7 +58,7 @@ include::../test/RecordSpecificationTest.groovy[tags=record_message_equivalent,i
Note the special naming convention for record getters. They are the same name as the field
(rather than the often common JavaBean convention of capitalized with a "get" prefix).
-Rather than refering to a record's fields or properties, the term _component_
+Rather than referring to a record's fields or properties, the term _component_
is typically used for records. So our `Message` record has `from`, `to`, and `body` components.
Like in Java, you can override the normally implicitly supplied methods
diff --git a/src/spec/doc/_traits.adoc b/src/spec/doc/_traits.adoc
index d165755de5..9616119047 100644
--- a/src/spec/doc/_traits.adoc
+++ b/src/spec/doc/_traits.adoc
@@ -813,7 +813,7 @@ In order to make this contract explicit, and to make the type checker aware of t
a `@SelfType` annotation that will:
* let you declare the types that a class that implements this trait must inherit or implement
-* throw a compile time error if those type constraints are not satisfied
+* throw a compile-time error if those type constraints are not satisfied
So in our previous example, we can fix the trait using the `@groovy.transform.SelfType` annotation:
diff --git a/src/spec/doc/_type-checking-extensions.adoc b/src/spec/doc/_type-checking-extensions.adoc
index 0cda7b3cb5..a2f6fb6f4c 100644
--- a/src/spec/doc/_type-checking-extensions.adoc
+++ b/src/spec/doc/_type-checking-extensions.adoc
@@ -958,7 +958,7 @@ without the extension, the code would still pass.
=== Mixed mode compilation
In the previous section, we highlighted the fact that you can activate type checking extensions with
-`@CompileStatic`. In that context, the type checker would not complain any more about some unresolved variables or
+`@CompileStatic`. In that context, the type checker would not complain anymore about some unresolved variables or
unknown method calls, but it would still wouldn't know how to compile them statically.
Mixed mode compilation offers a third way, which is to instruct the compiler that whenever an unresolved variable
diff --git a/src/spec/doc/_working-with-io.adoc b/src/spec/doc/_working-with-io.adoc
index 91ebc2a3ca..12981a3b7c 100644
--- a/src/spec/doc/_working-with-io.adoc
+++ b/src/spec/doc/_working-with-io.adoc
@@ -281,7 +281,7 @@ There are also variations of `consumeProcessOutput` that make use of `StringBuff
`OutputStream` etc... For a complete list, please read the
http://docs.groovy-lang.org/latest/html/groovy-jdk/java/lang/Process.html[GDK API for java.lang.Process]
-In addition, these is a `pipeTo` command (mapped to `|`
+In addition, there is a `pipeTo` command (mapped to `|`
to allow overloading) which lets the output stream of one process be fed
into the input stream of another process.
diff --git a/src/spec/doc/core-closures.adoc b/src/spec/doc/core-closures.adoc
index 62d56f9a34..f9e945bb8f 100644
--- a/src/spec/doc/core-closures.adoc
+++ b/src/spec/doc/core-closures.adoc
@@ -223,7 +223,7 @@ include::../test/ClosuresSpecTest.groovy[tags=closure_this,indent=0]
<2> calling the closure will return the instance of `Enclosing` where the closure is defined
<3> in general, you will just want to use the shortcut `this` notation
<4> and it returns *exactly* the same object
-<5> if the closure is defined in a inner class
+<5> if the closure is defined in an inner class
<6> `this` in the closure *will* return the inner class, not the top-level one
<7> in case of nested closures, like here `cl` being defined inside the scope of `nestedClosures`
<8> then `this` corresponds to the closest outer class, not the enclosing closure!
@@ -250,7 +250,7 @@ include::../test/ClosuresSpecTest.groovy[tags=closure_owner,indent=0]
<2> calling the closure will return the instance of `Enclosing` where the closure is defined
<3> in general, you will just want to use the shortcut `owner` notation
<4> and it returns *exactly* the same object
-<5> if the closure is defined in a inner class
+<5> if the closure is defined in an inner class
<6> `owner` in the closure *will* return the inner class, not the top-level one
<7> but in case of nested closures, like here `cl` being defined inside the scope of `nestedClosures`
<8> then `owner` corresponds to the enclosing closure, hence a different object from `this`!
@@ -495,7 +495,7 @@ include::../test/ClosuresSpecTest.groovy[tags=left_curry,indent=0]
==== Right currying
-Similarily to left currying, it is possible to set the right-most parameter of a closure:
+Similarly to left currying, it is possible to set the right-most parameter of a closure:
[source,groovy]
----
@@ -554,7 +554,7 @@ The behavior of the cache can be tweaked using alternate methods:
* `memoizeAtLeast` will generate a new closure which caches *at least* _n_ values
* `memoizeBetween` will generate a new closure which caches *at least* _n_ values and *at most* _n_ values
-The cache used in all memoize variants is a LRU cache.
+The cache used in all memoize variants is an LRU cache.
=== Composition
diff --git a/src/spec/doc/core-differences-java.adoc b/src/spec/doc/core-differences-java.adoc
index cbb5264714..55b17b6bb2 100644
--- a/src/spec/doc/core-differences-java.adoc
+++ b/src/spec/doc/core-differences-java.adoc
@@ -169,7 +169,7 @@ new File('/path/to/file').withReader('UTF-8') { reader ->
WARNING: The implementation of anonymous inner classes and nested classes follow Java closely,
but there are some differences, e.g.
local variables accessed from within such classes don't have to be final.
-We piggy-back on some implementation details we use for `groovy.lang.Closure`
+We piggyback on some implementation details we use for `groovy.lang.Closure`
when generating inner class bytecode.
=== Static inner classes
diff --git a/src/spec/doc/core-domain-specific-languages.adoc b/src/spec/doc/core-domain-specific-languages.adoc
index 59998a807f..3838f7c815 100644
--- a/src/spec/doc/core-domain-specific-languages.adoc
+++ b/src/spec/doc/core-domain-specific-languages.adoc
@@ -132,7 +132,7 @@ This allows you to provide your own Java or Groovy objects which can take advant
[options="header"]
|======================
-|Operator | Method
+|Operator | Method
| `a + b` | a.plus(b)
| `a - b` | a.minus(b)
| `a * b` | a.multiply(b)
@@ -273,7 +273,7 @@ An illustration of this can be found in Groovy using the `TimeCategory`:
include::../test/metaprogramming/CategoryTest.groovy[tags=time_category,indent=0]
----
<1> using the `TimeCategory`, a property `minute` is added to the `Integer` class
-<2> similarily, the `months` method returns a `groovy.time.DatumDependentDuration` which can be used in calculus
+<2> similarly, the `months` method returns a `groovy.time.DatumDependentDuration` which can be used in calculus
Categories are lexically bound, making them a great fit for internal DSLs.
@@ -351,7 +351,7 @@ include::../test/DelegatesToSpecTest.groovy[tags=email_builder_usage,indent=0]
---------------------------------------
Then the type checker will know that there’s an `email` method accepting
-a `Closure`, but it will complain for every method call *inside* the
+a `Closure`, but it will complain about every method call *inside* the
closure, because `from`, for example, is not a method which is defined
in the class. Indeed, it’s defined in the `EmailSpec` class and it has
absolutely no hint to help it knowing that the closure delegate will, at
@@ -1032,7 +1032,7 @@ You can also share all the settings by simply sharing the config file.
If:
-* runtime metaprogramming doesn't allow you do do what you want
+* runtime metaprogramming doesn't allow you to do what you want
* you need to improve the performance of the execution of your DSLs
* you want to leverage the same syntax as Groovy but with different semantics
* you want to improve support for type checking in your DSLs
@@ -1080,7 +1080,7 @@ include::../../../subprojects/groovy-xml/src/spec/doc/_dom-builder.adoc[leveloff
==== NodeBuilder
-`NodeBuilder` is used for creating nested trees of gapi:groovy.util.Node[Node] objects for handling arbitrary data.
+`NodeBuilder` is used for creating nested trees of gapi:groovy.util.Node[Node] objects for handling arbitrary data.
To create a simple user list you use a `NodeBuilder` like this:
[source,groovy]
diff --git a/src/spec/doc/core-getting-started.adoc b/src/spec/doc/core-getting-started.adoc
index 4b4b6d6b2b..1858bfd188 100644
--- a/src/spec/doc/core-getting-started.adoc
+++ b/src/spec/doc/core-getting-started.adoc
@@ -107,7 +107,7 @@ That's all there is to it!
==== MacPorts
-If you're on MacOS and have https://www.macports.org[MacPorts] installed, you can run:
+If you're on macOS and have https://www.macports.org[MacPorts] installed, you can run:
[source,shell]
----
@@ -116,7 +116,7 @@ sudo port install groovy
==== Homebrew
-If you're on MacOS and have https://mxcl.github.com/homebrew[Homebrew] installed, you can run:
+If you're on macOS and have https://mxcl.github.com/homebrew[Homebrew] installed, you can run:
[source,shell]
----
diff --git a/src/spec/doc/core-metaprogramming.adoc b/src/spec/doc/core-metaprogramming.adoc
index 235e7d6d48..2ddf603f94 100644
--- a/src/spec/doc/core-metaprogramming.adoc
+++ b/src/spec/doc/core-metaprogramming.adoc
@@ -562,7 +562,7 @@ The following sections go into detail on how `ExpandoMetaClass` can be used in v
===== Methods
-Once the `ExpandoMetaClass` is accessed by calling the `metaClass` property, methods can added by using either the left shift
+Once the `ExpandoMetaClass` is accessed by calling the `metaClass` property, methods can be added by using either the left shift
`<<` or the `=` operator.
[NOTE]
@@ -677,8 +677,8 @@ class HTMLCodec {
The example above shows a codec implementation. Grails comes with various codec implementations each defined in a single class.
At runtime there will be multiple codec classes in the application classpath. At application startup the framework adds
-a `encodeXXX` and a `decodeXXX` method to certain meta-classes where `XXX` is the first part of the codec class name (e.g.
-`encodeHTML`). This mechanism is in the following shown in some Groovy pseudo-code:
+a `encodeXXX` and a `decodeXXX` method to certain metaclasses where `XXX` is the first part of the codec class name (e.g.
+`encodeHTML`). This mechanism is in the following shown in some Groovy pseudocode:
[source,groovy]
----
@@ -723,7 +723,7 @@ The following example shows how to override `invokeMethod`:
include::../test/metaprogramming/ExpandoMetaClassTest.groovy[tags=emc_invoke_method,indent=0]
----
-The first step in the `Closure` code is to lookup the `MetaMethod` for the given name and arguments. If the method
+The first step in the `Closure` code is to look up the `MetaMethod` for the given name and arguments. If the method
can be found everything is fine and it is delegated to. If not, a dummy value is returned.
[NOTE]
@@ -937,7 +937,7 @@ boilerplate code incorrect is reduced.
[[xform-ToString]]
===== `@groovy.transform.ToString`
-The `@ToString` AST transformation generates a human readable `toString` representation of the class. For example,
+The `@ToString` AST transformation generates a human-readable `toString` representation of the class. For example,
annotating the `Person` class like below will automatically generate the `toString` method for you:
[source,groovy]
@@ -1761,7 +1761,7 @@ include::../test/CodeGenerationASTTransformsTest.groovy[tags=autoimplement_excep
----
The fourth example illustrates the case of user supplied code. Our class is annotated with `@AutoImplement`,
-implements an interface, has an explcitly overriden `hasNext` method, and has an annotation attribute containing the
+implements an interface, has an explicitly overridden `hasNext` method, and has an annotation attribute containing the
supplied code for any supplied methods. Here is the class definition:
[source,groovy]
@@ -1807,7 +1807,7 @@ singleton, ...) by using a declarative style.
===== `@groovy.transform.BaseScript`
`@BaseScript` is used within scripts to indicate that the script should
-extend fron a custom script base class rather than `groovy.lang.Script`.
+extend from a custom script base class rather than `groovy.lang.Script`.
See the documentation for <<{core-domain-specific-languages}#dsl-basescript,domain specific languages>> for further details.
[[xform-Delegate]]
@@ -2085,7 +2085,7 @@ and some non-tail recursive calls are erroneously treated as tail recursive.
The `@Singleton` annotation can be used to implement the singleton design pattern on a class. The singleton instance
is defined eagerly by default, using class initialization, or lazily, in which case the field is initialized using
-double checked locking.
+double-checked locking.
[source,groovy]
----
@@ -2432,7 +2432,7 @@ generating code which will for example allow you to interrupt execution automati
===== `@groovy.transform.ThreadInterrupt`
One complicated situation in the JVM world is when a thread can't be stopped. The `Thread#stop` method exists but is
-deprecated (and isn't reliable) so your only chance relies in `Thread#interrupt`. Calling the latter will set the
+deprecated (and isn't reliable) so your only chance lies in `Thread#interrupt`. Calling the latter will set the
`interrupt` flag on the thread, but it will *not* stop the execution of the thread. This is problematic because it's the
responsibility of the code executing in the thread to check the interrupt flag and properly exit. This makes sense when
you, as a developer, know that the code you are executing is meant to be run in an independent thread, but in general,
@@ -3045,7 +3045,7 @@ transformations may only be applied in the semantic analysis phase or
later. Briefly, the compiler phases are:
* _Initialization_: source files are opened and environment configured
-* _Parsing_: the grammar is used to to produce tree of tokens representing
+* _Parsing_: the grammar is used to produce tree of tokens representing
the source code
* _Conversion_: An abstract syntax tree (AST) is created from token trees.
* _Semantic Analysis_: Performs consistency and validity checks that the
@@ -3339,10 +3339,10 @@ Although the `macro` method is used in this example to create a **statement** th
**expressions** as well, it depends on which `macro` signature you use:
- `macro(Closure)`: Create a given statement with the code inside the closure.
-- `macro(Boolean,Closure)`: if **true** wrap expressions inside the closure inside an statement, if **false** then return
+- `macro(Boolean,Closure)`: if **true** wrap expressions inside the closure inside a statement, if **false** then return
an expression
- `macro(CompilePhase, Closure)`: Create a given statement with the code inside the closure in a specific compile phase
-- `macro(CompilePhase, Boolean, Closure)`: Create an statement or an expression (true == statement, false == expression)
+- `macro(CompilePhase, Boolean, Closure)`: Create a statement or an expression (true == statement, false == expression)
in a specific compilation phase.
NOTE: All these signatures can be found at `org.codehaus.groovy.macro.runtime.MacroGroovyMethods`
@@ -3478,7 +3478,7 @@ assert null == safe(safe(nullObject.hashcode()).toString())
==== Testing AST transformations
===== Separating source trees
-This section is about good practices with regards to testing AST transformations. Previous sections highlighted the fact
+This section is about good practices in regard to testing AST transformations. Previous sections highlighted the fact
that to be able to execute an AST transformation, it has to be precompiled. It might sound obvious but a lot of people
get caught on this, trying to use an AST transformation in the same source tree as where it is defined.
diff --git a/src/spec/doc/core-object-orientation.adoc b/src/spec/doc/core-object-orientation.adoc
index 0c261b6b50..65d5a19a9a 100644
--- a/src/spec/doc/core-object-orientation.adoc
+++ b/src/spec/doc/core-object-orientation.adoc
@@ -120,7 +120,7 @@ List<String> roles = ['Trinity', 'Morpheus']
----
Java employs type erasure for backwards compatibility with earlier versions of Java.
-Dynamic Groovy can be thought of as more agressively applying type erasure.
+Dynamic Groovy can be thought of as more aggressively applying type erasure.
In general, less generics type information will be checked at compile time.
Groovy's static nature employs similar checks to Java with regard to generics information.
@@ -128,7 +128,7 @@ Groovy's static nature employs similar checks to Java with regard to generics in
Groovy classes are very similar to Java classes, and are compatible with Java ones at JVM level.
They may have methods, fields and properties (think JavaBeans properties but with less boilerplate).
-Classes and class members can have the same modifiers (public, protected, private, static, etc) as in Java
+Classes and class members can have the same modifiers (public, protected, private, static, etc.) as in Java
with some minor differences at the source level which are explained shortly.
The key differences between Groovy classes and their Java counterparts are:
@@ -163,7 +163,7 @@ include::../test/ClassTest.groovy[tags=class_instantiation,indent=0]
=== Inner class
-Inner classes are defined within another classes. The enclosing class can use the inner class as usual. On the other side, a inner class can access members of its enclosing class, even if they are private. Classes other than the enclosing class are not allowed to access inner classes. Here is an example:
+Inner classes are defined within another classes. The enclosing class can use the inner class as usual. On the other side, an inner class can access members of its enclosing class, even if they are private. Classes other than the enclosing class are not allowed to access inner classes. Here is an example:
[source,groovy]
----
@@ -339,7 +339,7 @@ Groovy supports two invocation styles:
To create an object by using positional parameters, the respective class needs to declare one or more
constructors. In the case of multiple constructors, each must have a unique type signature. The constructors can also
-added to the class using the gapi:groovy.transform.TupleConstructor[] annotation.
+be added to the class using the gapi:groovy.transform.TupleConstructor[] annotation.
Typically, once at least one constructor is declared, the class can only be instantiated by having one of its
constructors called. It is worth noting that, in this case, you can't normally create the class with named parameters.
@@ -397,7 +397,7 @@ is a Map but there are also additional positional parameters. Use this style wit
=== Methods
-Groovy methods are quite similar to other languages. Some peculiarities will be shown in the next subsections.
+Groovy methods are quite similar to other languages. Some peculiarities will be shown in the next subsections.
==== Method definition
@@ -752,7 +752,7 @@ which defines the property:
include::../test/ClassTest.groovy[tags=property_access,indent=0]
----
<1> `this.name` will directly access the field because the property is accessed from within the class that defines it
-<2> similarily a read access is done directly on the `name` field
+<2> similarly a read access is done directly on the `name` field
<3> write access to the property is done outside of the `Person` class so it will implicitly call `setName`
<4> read access to the property is done outside of the `Person` class so it will implicitly call `getName`
<5> this will call the `name` method on `Person` which performs a direct access to the field
@@ -778,7 +778,7 @@ include::../test/ClassTest.groovy[tags=pseudo_properties,indent=0]
----
<1> writing `p.name` is allowed because there is a pseudo-property `name`
<2> reading `p.age` is allowed because there is a pseudo-readonly property `age`
-<3> writing `p.groovy` is allowed because there is a pseudo-writeonly property `groovy`
+<3> writing `p.groovy` is allowed because there is a pseudo-write-only property `groovy`
This syntactic sugar is at the core of many DSLs written in Groovy.
@@ -1145,7 +1145,7 @@ we will imagine two annotations, each of them accepting one argument:
include::../test/ClassTest.groovy[tags=collected_ann_explosive,indent=0]
----
-And suppose that you want create a meta-annotation named `@Explosive`:
+And suppose that you want to create a meta-annotation named `@Explosive`:
[source,groovy]
----
@@ -1205,8 +1205,8 @@ and then place your meta-annotation on a class that already has an explicit `@To
annotation. Should this be an error? Should both annotations be applied? Does one take
priority over the other? There is no correct answer. In some scenarios it might be
quite appropriate for any of these answers to be correct. So, rather than trying to
-preempt one correct way to handle the duplicate annotation issue, Groovy let's you
-write your own custom meta-annotation processors (covered next) and let's you write
+preempt one correct way to handle the duplicate annotation issue, Groovy lets you
+write your own custom meta-annotation processors (covered next) and lets you write
whatever checking logic you like within AST transforms - which are a frequent target for
aggregating. Having said that, by simply setting the `mode`, a number of commonly
expected scenarios are handled automatically for you within any extra coding.
diff --git a/src/spec/doc/core-operators.adoc b/src/spec/doc/core-operators.adoc
index 50dde78560..7c3718864a 100644
--- a/src/spec/doc/core-operators.adoc
+++ b/src/spec/doc/core-operators.adoc
@@ -731,7 +731,7 @@ include::../test/OperatorsTest.groovy[tags=spaceship,indent=0]
[[subscript-operator]]
=== Subscript operator
-The subscript operator is a short hand notation for `getAt` or `putAt`, depending on whether you find it on
+The subscript operator is a shorthand notation for `getAt` or `putAt`, depending on whether you find it on
the left hand side or the right hand side of an assignment:
[source,groovy]
diff --git a/src/spec/doc/core-program-structure.adoc b/src/spec/doc/core-program-structure.adoc
index 8412f1d5ff..baded9edce 100644
--- a/src/spec/doc/core-program-structure.adoc
+++ b/src/spec/doc/core-program-structure.adoc
@@ -31,7 +31,7 @@ This chapter covers the program structure of the Groovy programming language.
== Package names
-Package names play exactly the same role as in Java. They allows us to separate the code base without any conflicts. Groovy classes must specify their package before the class definition, else the default package is assumed.
+Package names play exactly the same role as in Java. They allow us to separate the code base without any conflicts. Groovy classes must specify their package before the class definition, else the default package is assumed.
Defining a package is very similar to Java:
@@ -62,7 +62,7 @@ Default imports are the imports that Groovy language provides by default. For ex
include::../test/PackageTest.groovy[tags=default_import,indent=0]
----
-The same code in Java needs an import statement to `Date` class like this: ++import java.util.Date++. Groovy by default imports these classes for you.
+The same code in Java needs an import statement to `Date` class like this: ++import java.util.Date++. Groovy by default imports these classes for you.
The below imports are added by groovy for you:
@@ -91,7 +91,7 @@ include::../test/PackageTest.groovy[tags=import_statement,indent=0]
=== Star import
-Groovy, like Java, provides a special way to import all classes from a package using `*`, the so called star import. `MarkupBuilder` is a class which is in package `groovy.xml`, alongside another class called `StreamingMarkupBuilder`. In case you need to use both classes, you can do:
+Groovy, like Java, provides a special way to import all classes from a package using `*`, the so-called star import. `MarkupBuilder` is a class which is in package `groovy.xml`, alongside another class called `StreamingMarkupBuilder`. In case you need to use both classes, you can do:
[source,groovy]
----
@@ -105,7 +105,7 @@ That's perfectly valid code. But with a `*` import, we can achieve the same effe
include::../test/PackageTest.groovy[tags=star_import,indent=0]
----
-One problem with `*` imports is that they can clutter your local namespace. But with the kinds of aliasing provided by Groovy, this can be solved easily.
+One problem with `*` imports is that they can clutter your local namespace. But with the kinds of aliasing provided by Groovy, this can be solved easily.
=== Static import
@@ -143,7 +143,7 @@ Now, that's clean!
A static star import is very similar to the regular star import. It will import all the static methods from the given class.
-For example, lets say we need to calculate sines and cosines for our application.
+For example, lets say we need to calculate sines and cosines for our application.
The class `java.lang.Math` has static methods named `sin` and `cos` which fit our need. With the help of a static star import, we can do:
[source,groovy]
@@ -266,7 +266,7 @@ method that the compiler will generate and will *not* be visible outside of the
a variable will *not* be visible in other methods of the script
* if the variable is undeclared, it goes into the gapi:groovy.lang.Script#getBinding()[script binding]. The binding is
visible from the methods, and is especially important if you use a script to interact with an application and need to
-share data between the script and the application. Readers might refer to the
+share data between the script and the application. Readers might refer to the
<<{guide-integrating}#_integrating_groovy_in_a_java_application,integration guide>> for more information.
TIP: Another approach to making a variable visible to all methods, is to use the
diff --git a/src/spec/doc/core-semantics.adoc b/src/spec/doc/core-semantics.adoc
index 2098da4edf..b217c9c445 100644
--- a/src/spec/doc/core-semantics.adoc
+++ b/src/spec/doc/core-semantics.adoc
@@ -416,7 +416,7 @@ Which will print the value for each sub-expression:
include::../test/semantics/PowerAssertTest.groovy[tags=assert_error_2,indent=0]
----
-In case you don't want a pretty printed error message like above, you can fallback to a custom error message by
+In case you don't want a pretty printed error message like above, you can fall back to a custom error message by
changing the optional message part of the assertion, like in this example:
[source,groovy]
@@ -597,7 +597,7 @@ NOTE: array access are zero-based in GPath expressions
==== GPath for XML navigation
-Here is an example with a XML document and various form of GPath expressions:
+Here is an example with an XML document and various form of GPath expressions:
[source,groovy]
----
include::../test/semantics/GPathTest.groovy[tags=gpath_on_xml_1,indent=0]
@@ -681,7 +681,7 @@ include::../test/CoercionTest.groovy[tags=method_call_with_implicit_coercion,ind
-----
As you can see, this has the advantage of letting you use the closure syntax for method calls, that is to say put the
-closure outside of the parenthesis, improving the readability of your code.
+closure outside the parenthesis, improving the readability of your code.
==== Closure to arbitrary type coercion
@@ -876,7 +876,7 @@ Method calls can omit the parentheses if there is at least one parameter and the
include::../test/semantics/OptionalityTest.groovy[tags=optional_parentheses,indent=0]
----
-Parentheses are required for method calls without parameters or ambiguous method calls:
+Parentheses are required for method calls without parameters or ambiguous method calls:
[source,groovy]
----
@@ -926,7 +926,7 @@ include::../test/semantics/OptionalityTest.groovy[tags=omitted_return_keyword,in
=== Optional public keyword
-By default, Groovy classes and methods are `public`. Therefore this class:
+By default, Groovy classes and methods are `public`. Therefore this class:
[source,groovy]
----
@@ -1502,7 +1502,7 @@ include::../test/typing/TypeCheckingTest.groovy[tags=method_not_type_checked,ind
The example above shows a class that Groovy will be able to compile. However, if you try to create an instance of `MyService` and call the
`doSomething` method, then it will fail *at runtime*, because `printLine` doesn't exist. Of course, we already showed how Groovy could make
-this a perfectly valid call, for example by catching `MethodMissingException` or implementing a custom meta-class, but if you know you're
+this a perfectly valid call, for example by catching `MethodMissingException` or implementing a custom metaclass, but if you know you're
not in such a case, `@TypeChecked` comes handy:
[source,groovy]
@@ -1578,7 +1578,7 @@ include::../test/typing/TypeCheckingTest.groovy[tags=typeinference_field_vs_loca
Why such a difference? The reason is _thread safety_. At compile time, we can't make *any* guarantee about the type of
a field. Any thread can access any field at any time and between the moment a field is assigned a variable of some
-type in a method and the time is is used the line after, another thread may have changed the contents of the field. This
+type in a method and the time is used the line after, another thread may have changed the contents of the field. This
is not the case for local variables: we know if they "escape" or not, so we can make sure that the type of a variable is
constant (or not) over time. Note that even if a field is final, the JVM makes no guarantee about it, so the type checker
doesn't behave differently if a field is final or not.
@@ -1825,7 +1825,7 @@ In Groovy, we could write:
include::../test/typing/TypeCheckingTest.groovy[tags=groovy_method_selection,indent=0]
----
-But this time, it will return `6`, because the method which is chosen is chosen *at runtime*, based on the _actual_
+But this time, it will return `6`, because the method which is chosen *at runtime*, based on the _actual_
argument types. So at runtime, `o` is a `String` so the `String` variant is used. Note that this behavior has nothing
to do with type checking, it's the way Groovy works in general: dynamic dispatch.
@@ -1979,7 +1979,7 @@ include::../test/typing/TypeCheckingTest.groovy[tags=cl_pt_workaround,indent=0]
----
<1> the type of `it` needs to be declared explicitly
-By explicitly declaring the type of the `it` variable, you can workaround the problem and make this code statically
+By explicitly declaring the type of the `it` variable, you can work around the problem and make this code statically
checked.
====== Parameters inferred from single-abstract method types
@@ -1997,8 +1997,8 @@ include::../test/typing/TypeCheckingTest.groovy[tags=cl_pt_workaround_sam,indent
<3> there's no need to declare the type of the `it` variable anymore
<4> `it.age` compiles properly, the type of `it` is inferred from the `Predicate#apply` method signature
-TIP: By using this technique, we leverage the _automatic coercion of closures to SAM types_ feature of Groovy. The
-question whether you should use a _SAM type_ or a _Closure_ really depends on what you need to do. In a lot of cases,
+TIP: By using this technique, we leverage the _automatic coercion of closures to SAM types_ feature of Groovy.
+Whether you should use a _SAM type_ or a _Closure_ really depends on what you need to do. In a lot of cases,
using a SAM interface is enough, especially if you consider functional interfaces as they are found in Java 8. However,
closures provide features that are not accessible to functional interfaces. In particular, closures can have a delegate,
and owner and can be manipulated as objects (for example, cloned, serialized, curried, ...) before being called. They can
@@ -2152,7 +2152,7 @@ In short, the lack of the `@ClosureParams` annotation on a method accepting a `C
A third optional argument is named _conflictResolutionStrategy_. It can reference a class (extending from
`ClosureSignatureConflictResolver`) that can perform additional resolution of parameter types if more than
-one are found after initial inference calculations are complete. Groovy comes with the a default type resolver
+one are found after initial inference calculations are complete. Groovy comes with a default type resolver
which does nothing, and another which selects the first signature if multiple are found. The resolver is
only invoked if more than one signature is found and is by design a post processor. Any statements which need
injected typing information must pass one of the parameter signatures determined through type hints. The
@@ -2171,7 +2171,7 @@ discussed in a link:core-domain-specific-languages.html#section-delegatesto[spec
In the <<static-type-checking,type checking section>>, we have seen that Groovy provides optional type checking thanks to the
`@TypeChecked` annotation. The type checker runs at compile time and performs a static analysis of dynamic code. The
program will behave exactly the same whether type checking has been enabled or not. This means that the `@TypeChecked`
-annotation is neutral with regards to the semantics of a program. Even though it may be necessary to add type information
+annotation is neutral in regard to the semantics of a program. Even though it may be necessary to add type information
in the sources so that the program is considered type safe, in the end, the semantics of the program are the same.
While this may sound fine, there is actually one issue with this: type checking of dynamic code, done at compile time, is
diff --git a/src/spec/doc/core-syntax.adoc b/src/spec/doc/core-syntax.adoc
index f0358a4122..8f022097d6 100644
--- a/src/spec/doc/core-syntax.adoc
+++ b/src/spec/doc/core-syntax.adoc
@@ -500,7 +500,7 @@ resulting in an updated string containing the new number value.
[NOTE]
An embedded closure expression taking more than one parameter will generate an exception at runtime.
-Only closures with zero or one parameters are allowed.
+Only closures with zero or one parameter are allowed.
==== Interoperability with Java
@@ -513,7 +513,7 @@ the `toString()` method of the GString is automatically and transparently called
include::../test/SyntaxTest.groovy[tags=java_gstring_interop_1,indent=0]
----
<1> We create a GString variable
-<2> We double check it's an instance of the GString
+<2> We double-check it's an instance of the GString
<3> We then pass that GString to a method taking a String as parameter
<4> The signature of the `takeString()` method explicitly says its sole parameter is a String
<5> We also verify that the parameter is indeed a String and not a GString.
@@ -757,13 +757,13 @@ include::../test/SyntaxTest.groovy[tags=subscript_and_leftshift,indent=0]
<5> Access two elements at once, returning a new list containing those two elements
<6> Use a range to access a range of values from the list, from a start to an end element position
-As lists can be heterogeneous in nature, lists can also contain other lists to create multi-dimensional lists:
+As lists can be heterogeneous in nature, lists can also contain other lists to create multidimensional lists:
[source,groovy]
----
include::../test/SyntaxTest.groovy[tags=multi_dim_list,indent=0]
----
-<1> Define a list of list of numbers
+<1> Define a list of numbers
<2> Access the second element of the top-most list, and the first element of the inner list
== Arrays
diff --git a/src/spec/doc/core-testing-guide.adoc b/src/spec/doc/core-testing-guide.adoc
index 32ac1462a2..f0649d7558 100644
--- a/src/spec/doc/core-testing-guide.adoc
+++ b/src/spec/doc/core-testing-guide.adoc
@@ -85,7 +85,7 @@ Another important difference from Java is that in Groovy assertions are _enabled
decision to remove the possibility to deactivate assertions. Or, as Bertrand Meyer stated, ``it makes no sense to take
off your swim ring if you put your feet into real water``.
-One thing to be aware of are methods with side-effects inside Boolean expressions in power assertion statements. As
+One thing to be aware of are methods with side effects inside Boolean expressions in power assertion statements. As
the internal error message construction mechanism does only store references to instances under target,
it happens that the error message text is invalid at rendering time in case of side-effecting methods involved:
@@ -107,7 +107,7 @@ assert [[1,2,3,3,3,3,4]].first().unique() == [1,2,3]
[NOTE]
If you choose to provide a custom assertion error message this can be done by using the Java syntax `assert
expression1 : expression2` where `expression1` is the Boolean expression and `expression2` is the custom error message.
- Be aware though that this will disable the power assert and will fully fallback to custom
+ Be aware though that this will disable the power assert and will fully fall back to custom
error messages on assertion errors.
=== Mocking and Stubbing
@@ -145,7 +145,7 @@ useful in simple cases none-the-less.
Classes or interfaces holding a single method, including SAM (single abstract method) classes, can be used to coerce
a closure block to be an object of the given type. Be aware that for doing this, Groovy internally create a proxy object
descending for the given class. So the object will not be a direct instance of the given class. This important if, for
-example, the generated proxy object's meta-class is altered afterwards.
+example, the generated proxy object's metaclass is altered afterwards.
Let's have an example on coercing a closure to be of a specific type:
@@ -209,7 +209,7 @@ include::../test/testingguide/MockingExampleTests.groovy[tags=stubFor,indent=0]
<3> a `Closure` is passed to `use` which enables the stubbing functionality
<4> a call to `verify` (optional) checks whether the number of method calls is as expected
-`MockFor` and `StubFor` can not be used to test statically compiled classes e.g for Java classes or Groovy classes that
+`MockFor` and `StubFor` can not be used to test statically compiled classes e.g. for Java classes or Groovy classes that
make use of `@CompileStatic`. To stub and/or mock these classes you can use Spock or one of the Java mocking libraries.
[[testing_guide_emc]]
@@ -219,7 +219,7 @@ Groovy includes a special `MetaClass` the so-called `ExpandoMetaClass` (EMC). It
constructors, properties and static methods using a neat closure syntax.
Every `java.lang.Class` is supplied with a special `metaClass` property that will give a reference to an
-`ExpandoMetaClass` instance. The expando meta-class is not restricted to custom classes, it can be used for
+`ExpandoMetaClass` instance. The expando metaclass is not restricted to custom classes, it can be used for
JDK classes like for example `java.lang.String` as well:
[source,groovy]
@@ -249,8 +249,8 @@ help of `ExpandoMetaClass`. This lets the domain object register itself in the S
for injection of services or other beans controlled by the dependency-injection container.
If you want to change the `metaClass` property on a per test method level you need to remove the changes that were
-done to the meta-class, otherwise those changes would be persistent across test method calls. Changes are removed by
-replacing the meta-class in the `GroovyMetaClassRegistry`:
+done to the metaclass, otherwise those changes would be persistent across test method calls. Changes are removed by
+replacing the metaclass in the `GroovyMetaClassRegistry`:
[source,groovy]
----
@@ -262,7 +262,7 @@ the changes in the cleanup method of your chosen testing runtime. A good example
https://github.com/grails/grails-core/blob/master/grails-bootstrap/src/main/groovy/grails/build/support/MetaClassRegistryCleaner.java[in the Grails web
development framework].
-Besides using the `ExpandoMetaClass` on a class-level, there is also support for using the meta-class on a per-object
+Besides using the `ExpandoMetaClass` on a class-level, there is also support for using the metaclass on a per-object
level:
[source,groovy]
@@ -270,8 +270,8 @@ level:
include::../test/testingguide/MockingExampleTests.groovy[tags=emc5,indent=0]
----
-In this case the meta-class change is related to the instance only. Depending on the test scenario this might be a better
-fit than the global meta-class change.
+In this case the metaclass change is related to the instance only. Depending on the test scenario this might be a better
+fit than the global metaclass change.
=== GDK Methods
@@ -510,7 +510,7 @@ language features in third party libraries, for example, by using Groovy AST tra
This section should not serve as detailed guide on how to use Spock, it should rather give an impression what Spock
is about and how it can be leveraged for unit, integration, functional or any other type of testing.
-The next section we will have an first look at the anatomy of a Spock specification. It should give a
+The next section we will have a first look at the anatomy of a Spock specification. It should give a
pretty good feeling on what Spock is up to.
=== Specifications
@@ -619,7 +619,7 @@ browser.drive {
}
---------------------------------------------------------------------------------------------------
<1> A new `Browser` instance is created. In this case it uses the Selenium `FirefoxDriver` and sets the `baseUrl`.
-<2> `go` is used to navigate to an URL or relative URI
+<2> `go` is used to navigate to a URL or relative URI
<3> `$` together with CSS selectors is used to access the `username` and `password` DOM fields.
The `Browser` class comes with a `drive` method that delegates all method/property calls to the current
diff --git a/src/spec/doc/grape.adoc b/src/spec/doc/grape.adoc
index 8dfd68cbac..7645781632 100644
--- a/src/spec/doc/grape.adoc
+++ b/src/spec/doc/grape.adoc
@@ -117,7 +117,7 @@ proxy server, you can specify those settings on the command like via the
groovy -Dhttp.proxyHost=yourproxy -Dhttp.proxyPort=8080 yourscript.groovy
-------------------------------------------------------------------------
-Or you can make this system wide by adding these properties to your
+Or you can make this system-wide by adding these properties to your
JAVA_OPTS environment variable:
------------------------------------------------------------
@@ -234,7 +234,7 @@ annotation to apply to only a subset of the Grab annotations.
=== Method call
Typically a call to grab will occur early in the script or in class
-initialization. This is to insure that the libraries are made available
+initialization. This is to ensure that the libraries are made available
to the ClassLoader before the groovy code relies on the code. A couple
of typical calls may appear as follows:
@@ -303,7 +303,7 @@ runtime exception.
[[Grape-ArgumentsMaparguments]]
==== Arguments Map arguments
-* `classLoader:` - <GroovyClassLaoder> or <RootClassLoader> - The
+* `classLoader:` - <GroovyClassLoader> or <RootClassLoader> - The
ClassLoader to add resolved Jars to
* `refObject:` - <Object> - The closest parent ClassLoader for the
object’s class will be treated as though it were passed in as
diff --git a/src/spec/doc/guide-integrating.adoc b/src/spec/doc/guide-integrating.adoc
index 182615eb22..8c6fbd14d2 100644
--- a/src/spec/doc/guide-integrating.adoc
+++ b/src/spec/doc/guide-integrating.adoc
@@ -55,7 +55,7 @@ include::../test/IntegrationTest.groovy[tags=eval_x,indent=0]
<4> Simple evaluation with three bound parameters named `x`, `y` and `z`
The `Eval` class makes it very easy to evaluate simple scripts, but doesn't scale: there is no caching of the script, and
-it isn't meant to evaluate more than one liners.
+it isn't meant to evaluate more than one-liners.
[[integ-groovyshell]]
=== GroovyShell
diff --git a/src/spec/doc/performance-guide.adoc b/src/spec/doc/performance-guide.adoc
index aec25ef41a..b652505198 100644
--- a/src/spec/doc/performance-guide.adoc
+++ b/src/spec/doc/performance-guide.adoc
@@ -29,5 +29,5 @@ The Parrot parser is based on antlr4 and introduced since Groovy 3.0.0. It provi
| groovy.parallel.parse | Parsing groovy source files in parallel. | `false` util Groovy 4.0.0 | 3.0.5+ | -Dgroovy.parallel.parse=true
| groovy.antlr4.cache.threshold | antlr4 relies on DFA cache heavily for better performance, so antlr4 will not clear DFA cache, thus OutOfMemoryError will probably occur. Groovy trades off parsing performance and memory usage, when the count of Groovy source files parsed hits the cache threshold, the DFA cache will be cleared. *Note:* `0` means never clearing DFA cache, so requiring bigger JVM heap size. Or set a greater value, e.g. 200 to clear DFA cache if threshold hits. **Note: ** t [...]
| groovy.antlr4.sll.threshold | Parrot parser will try SLL mode and then try LL mode if SLL failed. But the more tokens to parse, the more likely SLL will fail. If SLL threshold hits, SLL will be skipped. Setting the threshold to `0` means never trying SLL mode, which is not recommended at most cases because SLL is the fastest mode though SLL is less powerful than LL. **Note: ** the threshold specified is the token count | `-1` (disabled by default) | 3.0.9+ | -Dgroovy.antlr4.sll.threshold=1000
-| groovy.antlr4.clear.lexer.dfa.cache | Clear the DFA cache for lexer. The DFA cache for lexer is always small and important for parsing performance, so it's strongly recommended to leave it as it is util OutOfMemoryError will truely occur | `false`| 3.0.9+ | -Dgroovy.antlr4.clear.lexer.dfa.cache=true
+| groovy.antlr4.clear.lexer.dfa.cache | Clear the DFA cache for lexer. The DFA cache for lexer is always small and important for parsing performance, so it's strongly recommended to leave it as it is until OutOfMemoryError will truly occur | `false`| 3.0.9+ | -Dgroovy.antlr4.clear.lexer.dfa.cache=true
|=======================================================================
diff --git a/src/spec/doc/style-guide.adoc b/src/spec/doc/style-guide.adoc
index 0817ef4a0a..9315fab66b 100644
--- a/src/spec/doc/style-guide.adoc
+++ b/src/spec/doc/style-guide.adoc
@@ -276,7 +276,7 @@ class Person {
}
----
-As you can see, a free standing 'field' without modifier visibility actually
+As you can see, a freestanding 'field' without modifier visibility actually
makes the Groovy compiler to generate a private field and a getter and setter for you.
When using such POGOs from Java, the getter and setter are indeed there, and can be used as usual, of course.
@@ -475,7 +475,7 @@ assert "foooo/baaaaar" ==~ /fo+\/ba+r/
The advantage of the "slashy" notation is that you don't need to double escape backslashes, making working with regex a bit simpler.
Last but not least, prefer using single quoted strings when you need string constants,
-and use double quoted strings when you are explicitly relying on string interpolation.
+and use double-quoted strings when you are explicitly relying on string interpolation.
== Native syntax for data structures
@@ -588,7 +588,7 @@ Same thing for collections, etc.
Thus, you can use some shortcuts in things like `while()`, `if()`, the ternary operator, the Elvis operator (see below), etc.
-It's even possible to customize the Groovy Truth, by adding an boolean `asBoolean()` method to your classes!
+It's even possible to customize the Groovy Truth, by adding a boolean `asBoolean()` method to your classes!
== Safe graph navigation
diff --git a/src/spec/doc/tools-groovyc.adoc b/src/spec/doc/tools-groovyc.adoc
index 240ecd1e7e..43ec83453f 100644
--- a/src/spec/doc/tools-groovyc.adoc
+++ b/src/spec/doc/tools-groovyc.adoc
@@ -45,7 +45,7 @@ a number of command line switches:
| | --temp | Temporary directory for the compiler |
| | --encoding | Encoding of the source files | groovyc --encoding utf-8 script.groovy
| | --help | Displays help for the command line groovyc tool | groovyc --help
-| -d | | Specify where to place generated class files. | groovyc -d target Person.groovy
+| -d | | Specify where to place generated class files. | groovyc -d target Person.groovy
| -v | --version | Displays the compiler version | groovyc -v
| -e | --exception | Displays the stack trace in case of compilation error | groovyc -e script.groovy
| -j | --jointCompilation* | Enables joint compilation | groovyc -j A.groovy B.java
@@ -189,7 +189,7 @@ typical Maven build phases normally. For example, `mvn test` will
execute the test phase, compiling Groovy source and Groovy test source
and finally executing the unit tests. If you run `mvn jar` it will
execute the jar phase bundling up all of your compiled production
-classes into a jar after all of the unit tests pass. For more detail on
+classes into a jar after all the unit tests pass. For more detail on
Maven build phases consult the Maven2 documentation.
=== GMaven and GMavenPlus
@@ -245,7 +245,7 @@ compilation in the normal Groovy compiler way. This allows mixing of
Java and Groovy files without constraint.
Joint compilation can be enabled using the `-j` flag with the command-line compiler,
-or using using a nested tag and all the attributes and further nested tags as required
+or using a nested tag and all the attributes and further nested tags as required
for the Ant task.
It is important to know that if you don't enable joint compilation and try to compile