groovy-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pa...@apache.org
Subject [groovy] branch master updated: finesse some wording for java.time upto/downto doco and fix some doco typos
Date Tue, 09 Apr 2019 12:44:41 GMT
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 1029030  finesse some wording for java.time upto/downto doco and fix some doco typos
1029030 is described below

commit 1029030bfe3afbcd89bba6642192eba2e9c5c3b4
Author: Daniel Sun <sunlan@apache.org>
AuthorDate: Tue Apr 9 22:44:15 2019 +1000

    finesse some wording for java.time upto/downto doco and fix some doco typos
---
 .../groovy/lang/MetaClassRegistryChangeEvent.java      |  2 +-
 .../groovy/classgen/asm/BinaryExpressionHelper.java    |  2 +-
 .../codehaus/groovy/runtime/DefaultGroovyMethods.java  |  2 +-
 .../metaclass/ThreadManagedMetaBeanProperty.java       |  2 +-
 .../transform/stc/StaticTypeCheckingVisitor.java       |  2 +-
 .../org/codehaus/groovy/vmplugin/v7/IndyInterface.java |  2 +-
 src/spec/doc/core-closures.adoc                        |  4 ++--
 src/spec/doc/core-semantics.adoc                       |  2 +-
 src/spec/doc/core-syntax.adoc                          |  2 +-
 src/test/groovy/SwitchTest.groovy                      |  2 +-
 .../groovy-console/src/spec/doc/groovy-console.adoc    |  2 +-
 .../src/spec/doc/working-with-datetime-types.adoc      | 18 +++++++++---------
 .../spec/test/gdk/WorkingWithDateTimeTypesTest.groovy  |  8 ++++----
 subprojects/groovy-jmx/src/spec/doc/jmx.adoc           |  2 +-
 .../src/spec/doc/template-engines.adoc                 |  2 +-
 15 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/src/main/groovy/groovy/lang/MetaClassRegistryChangeEvent.java b/src/main/groovy/groovy/lang/MetaClassRegistryChangeEvent.java
index 0487cc1..0077365 100644
--- a/src/main/groovy/groovy/lang/MetaClassRegistryChangeEvent.java
+++ b/src/main/groovy/groovy/lang/MetaClassRegistryChangeEvent.java
@@ -33,7 +33,7 @@ public class MetaClassRegistryChangeEvent extends EventObject {
     /**
      *Constructs a new MetaClassRegistryChangeEvent Object
      *
-     * @param source The object the the event originates at.
+     * @param source The object the event originates at.
      * @param instance Object instance  the MetaClass change is on.
      * @param clazz  The class that is affected by the registry change
      * @param oldMetaClass The old MetaClass
diff --git a/src/main/java/org/codehaus/groovy/classgen/asm/BinaryExpressionHelper.java b/src/main/java/org/codehaus/groovy/classgen/asm/BinaryExpressionHelper.java
index 3279c14..eaefc56 100644
--- a/src/main/java/org/codehaus/groovy/classgen/asm/BinaryExpressionHelper.java
+++ b/src/main/java/org/codehaus/groovy/classgen/asm/BinaryExpressionHelper.java
@@ -842,7 +842,7 @@ public class BinaryExpressionHelper {
         // this will load the callsite and the receiver normally in the wrong
         // order since the receiver is already present, but before the callsite
         // Therefore we use callSiteReceiverSwap to correct the order. 
-        // After this call the JVM operand stack will contain the the result of
+        // After this call the JVM operand stack will contain the result of
         // the method call... usually simply Object in operandStack
         controller.getCallSiteWriter().makeCallSite(
                 callSiteReceiverSwap,
diff --git a/src/main/java/org/codehaus/groovy/runtime/DefaultGroovyMethods.java b/src/main/java/org/codehaus/groovy/runtime/DefaultGroovyMethods.java
index b65f7fb..c969074 100644
--- a/src/main/java/org/codehaus/groovy/runtime/DefaultGroovyMethods.java
+++ b/src/main/java/org/codehaus/groovy/runtime/DefaultGroovyMethods.java
@@ -663,7 +663,7 @@ public class DefaultGroovyMethods extends DefaultGroovyMethodsSupport
{
     /**
      * Allows you to use a list of categories, specifying the list as varargs.
      * <code>use(CategoryClass1, CategoryClass2) { ... }</code>
-     * This method saves having to wrap the the category
+     * This method saves having to wrap the category
      * classes in a list.
      *
      * @param self  any Object
diff --git a/src/main/java/org/codehaus/groovy/runtime/metaclass/ThreadManagedMetaBeanProperty.java
b/src/main/java/org/codehaus/groovy/runtime/metaclass/ThreadManagedMetaBeanProperty.java
index e171041..5074908 100644
--- a/src/main/java/org/codehaus/groovy/runtime/metaclass/ThreadManagedMetaBeanProperty.java
+++ b/src/main/java/org/codehaus/groovy/runtime/metaclass/ThreadManagedMetaBeanProperty.java
@@ -32,7 +32,7 @@ import java.util.concurrent.ConcurrentHashMap;
 /**
  * This MetaBeanProperty will create a pseudo property whose value is bound to an object
  * using weak references. The values will go out of scope and be garbage collected when
- * the the object is collected
+ * the object is collected
  *
  * In fact, this class should be called ExpandoProperty.
  *
diff --git a/src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java
b/src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java
index cef2fce..2fe787a 100644
--- a/src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java
+++ b/src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java
@@ -3468,7 +3468,7 @@ public class StaticTypeCheckingVisitor extends ClassCodeVisitorSupport
{
 
                     // if the receiver is "this" or "implicit this", then we must make sure
that the compatible
                     // methods are only static if we are in a static context
-                    // if we are not in a static context but the the current receiver is
a static class, we must
+                    // if we are not in a static context but the current receiver is a static
class, we must
                     // ensure that all methods are either static or declared by the current
receiver or a superclass
                     if (!mn.isEmpty()
                             && (typeCheckingContext.isInStaticContext || (receiverType.getModifiers()
& Opcodes.ACC_STATIC) != 0)
diff --git a/src/main/java/org/codehaus/groovy/vmplugin/v7/IndyInterface.java b/src/main/java/org/codehaus/groovy/vmplugin/v7/IndyInterface.java
index 0352488..661105a 100644
--- a/src/main/java/org/codehaus/groovy/vmplugin/v7/IndyInterface.java
+++ b/src/main/java/org/codehaus/groovy/vmplugin/v7/IndyInterface.java
@@ -204,7 +204,7 @@ public class IndyInterface {
         private static CallSite realBootstrap(Lookup caller, String name, int callID, MethodType
type, boolean safe, boolean thisCall, boolean spreadCall) {
             // since indy does not give us the runtime types
             // we produce first a dummy call site, which then changes the target to one,
-            // that does the method selection including the the direct call to the 
+            // that does the method selection including the direct call to the
             // real method.
             MutableCallSite mc = new MutableCallSite(type);
             MethodHandle mh = makeFallBack(mc,caller.lookupClass(),name,callID,type,safe,thisCall,spreadCall);
diff --git a/src/spec/doc/core-closures.adoc b/src/spec/doc/core-closures.adoc
index 5f1ebcc..43f86a9 100644
--- a/src/spec/doc/core-closures.adoc
+++ b/src/spec/doc/core-closures.adoc
@@ -220,7 +220,7 @@ using an explicit `this`:
 include::{projectdir}/src/spec/test/ClosuresSpecTest.groovy[tags=closure_this,indent=0]
 ----
 <1> a closure is defined inside the `Enclosing` class, and returns `getThisObject`
-<2> calling the closure will return the instance of `Enclosing` where the the closure
is defined
+<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
@@ -247,7 +247,7 @@ it will return the direct enclosing object, be it a closure or a class:
 include::{projectdir}/src/spec/test/ClosuresSpecTest.groovy[tags=closure_owner,indent=0]
 ----
 <1> a closure is defined inside the `Enclosing` class, and returns `getOwner`
-<2> calling the closure will return the instance of `Enclosing` where the the closure
is defined
+<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
diff --git a/src/spec/doc/core-semantics.adoc b/src/spec/doc/core-semantics.adoc
index 5fe3f5d..1fef521 100644
--- a/src/spec/doc/core-semantics.adoc
+++ b/src/spec/doc/core-semantics.adoc
@@ -304,7 +304,7 @@ the code easier to read like in the following example:
 include::{projectdir}/src/spec/test/semantics/LabelsTest.groovy[tags=test_labels,indent=0]
 ----
 
-Despite not changing the semantics of the the labelled statement, it is possible to use labels
in the `break` instruction
+Despite not changing the semantics of the labelled statement, it is possible to use labels
in the `break` instruction
 as a target for jump, as in the next example. However, even if this is allowed, this coding
style is in general considered
 a bad practice:
 
diff --git a/src/spec/doc/core-syntax.adoc b/src/spec/doc/core-syntax.adoc
index 16fb6ed..72c0a4b 100644
--- a/src/spec/doc/core-syntax.adoc
+++ b/src/spec/doc/core-syntax.adoc
@@ -274,7 +274,7 @@ include::{projectdir}/src/spec/test/SyntaxTest.groovy[tags=triple_single_3,inden
 
 ==== Escaping special characters
 
-You can escape single quotes with the the backslash character to avoid terminating the string
literal:
+You can escape single quotes with the backslash character to avoid terminating the string
literal:
 
 [source,groovy]
 ----
diff --git a/src/test/groovy/SwitchTest.groovy b/src/test/groovy/SwitchTest.groovy
index 9ce1253..2aba958 100644
--- a/src/test/groovy/SwitchTest.groovy
+++ b/src/test/groovy/SwitchTest.groovy
@@ -83,7 +83,7 @@ class SwitchTest extends GroovyTestCase {
         assert result == expected, "Expected $expected but found $result when calling switch
with $x"
     }
 
-    // test the continue in switch, which should jump to the the while start
+    // test the continue in switch, which should jump to the while start
     void testSwitchScope() {
         def i = 0
         def j = 0
diff --git a/subprojects/groovy-console/src/spec/doc/groovy-console.adoc b/subprojects/groovy-console/src/spec/doc/groovy-console.adoc
index da259b7..d49639c 100644
--- a/subprojects/groovy-console/src/spec/doc/groovy-console.adoc
+++ b/subprojects/groovy-console/src/spec/doc/groovy-console.adoc
@@ -75,7 +75,7 @@ There are several shortcuts that you can use to run scripts or code snippets:
 * `Ctrl+Enter` and `Ctrl+R` are both shortcut keys for `Run Script`.
 * If you highlight just part of the text in the input area, then Groovy
 runs just that text.
-* The result of a script is the the value of the last expression
+* The result of a script is the value of the last expression
 executed.
 * You can turn the System.out capture on and off by selecting `Capture
 System.out` from the `Actions` menu
diff --git a/subprojects/groovy-datetime/src/spec/doc/working-with-datetime-types.adoc b/subprojects/groovy-datetime/src/spec/doc/working-with-datetime-types.adoc
index e4041c4..3853bd0 100644
--- a/subprojects/groovy-datetime/src/spec/doc/working-with-datetime-types.adoc
+++ b/subprojects/groovy-datetime/src/spec/doc/working-with-datetime-types.adoc
@@ -219,16 +219,16 @@ include::{projectdir}/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy[tags
 -------------------------------------
 
 The `upto` method will accomplish the same as the range in the above example.
-The `upto` method iterates from the earlier start value (inclusive) to the later end value
-(also inclusive), calling the closure with the incremented value once per iteration.
+The `upto` method iterates from the earlier `start` value (inclusive) to the later `end`
value
+(also inclusive), calling the closure with the incremented `next` value once per iteration.
 
 [source,groovy]
 -------------------------------------
 include::{projectdir}/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy[tags=date_upto_date,indent=0]
 -------------------------------------
 
-The `downto` method iterates in the opposite direction, from a later start value
-to an earlier end value.
+The `downto` method iterates in the opposite direction, from a later `start` value
+to an earlier `end` value.
 
 The unit of iteration for `upto`, `downto`, and ranges is the same as the unit for addition
 and subtraction: `LocalDate` iterates by one day at a time,
@@ -245,11 +245,11 @@ https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html#MON
 include::{projectdir}/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy[tags=date_upto_date_by_months,indent=0]
 -------------------------------------
 
-Since the start date is inclusive, the closure is called with date March 1st. The `upto`
method
-then increments the date by one month, yielding the date, April 1st. Because this date is
_after_ the
-specified end date of March 2nd, the iteration stops immediately, having only called the
closure
-once. This behavior is the same for the `downto` method except that the iteration will stop
-as soon as the the value of `end` becomes earlier than the targeted end date.
+Since the `start` date is inclusive, the closure is called with a `next` date value of March
1st.
+The `upto` method then increments the date by one month, yielding the date, April 1st.
+Because this date is _after_ the specified `end` date of March 2nd, the iteration stops immediately,
+having only called the closure once. This behavior is the same for the `downto` method except
that
+the iteration will stop as soon as the value of `next` becomes earlier than the targeted
`end` date.
 
 In short, when iterating with the `upto` or `downto` methods with a custom unit of iteration,
 the current value of iteration will never exceed the end value.
diff --git a/subprojects/groovy-datetime/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy
b/subprojects/groovy-datetime/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy
index 07eee46..4429351 100644
--- a/subprojects/groovy-datetime/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy
+++ b/subprojects/groovy-datetime/src/spec/test/gdk/WorkingWithDateTimeTypesTest.groovy
@@ -72,8 +72,8 @@ class WorkingWithDateTimeTypesTest extends GroovyTestCase {
         // tag::date_upto_date[]
         def start = LocalDate.now()
         def end = start + 6 // 6 days later
-        start.upto(end) { date ->
-            println date.dayOfWeek
+        start.upto(end) { next ->
+            println next.dayOfWeek
         }
         // end::date_upto_date[]
     }
@@ -84,8 +84,8 @@ class WorkingWithDateTimeTypesTest extends GroovyTestCase {
         def end = start + 1 // 1 day later
 
         int iterationCount = 0
-        start.upto(end, ChronoUnit.MONTHS) { date ->
-            println date
+        start.upto(end, ChronoUnit.MONTHS) { next ->
+            println next
             ++iterationCount
         }
 
diff --git a/subprojects/groovy-jmx/src/spec/doc/jmx.adoc b/subprojects/groovy-jmx/src/spec/doc/jmx.adoc
index 935e33a..09ba4c0 100644
--- a/subprojects/groovy-jmx/src/spec/doc/jmx.adoc
+++ b/subprojects/groovy-jmx/src/spec/doc/jmx.adoc
@@ -791,7 +791,7 @@ The snippet above shows all of the ways JmxBuilder allows you to describe
an ope
 
 - Operations **start() and stop()** are described by the "desc" key (this is enough since
there are no params).
 - In operation **setResource()** uses of a shorthand version of **params**: to describe the
parameters for the method.
-- **makeRequest()** uses the the extended descriptor syntax to describe all aspects of the
operation.
+- **makeRequest()** uses the extended descriptor syntax to describe all aspects of the operation.
 
 === Embedding Descriptor
 
diff --git a/subprojects/groovy-templates/src/spec/doc/template-engines.adoc b/subprojects/groovy-templates/src/spec/doc/template-engines.adoc
index 64210c4..56cf02a 100644
--- a/subprojects/groovy-templates/src/spec/doc/template-engines.adoc
+++ b/subprojects/groovy-templates/src/spec/doc/template-engines.adoc
@@ -76,7 +76,7 @@ include::{rootProjectDir}/subprojects/groovy-templates/src/spec/test/TemplateEng
 
 === Advanced Usage Note
 
-If you happen to be embedding your template directly in your script (as we did above) you
have to be careful about backslash escaping. Because the template string itself will be parsed
by Groovy before it is passed to the the templating framework, you have to escape any backslashes
inside GString expressions or scriptlet 'code' that are entered as part of a Groovy program.
E.g. if we wanted quotes around __The Big Apple__ above, we would use:
+If you happen to be embedding your template directly in your script (as we did above) you
have to be careful about backslash escaping. Because the template string itself will be parsed
by Groovy before it is passed to the templating framework, you have to escape any backslashes
inside GString expressions or scriptlet 'code' that are entered as part of a Groovy program.
E.g. if we wanted quotes around __The Big Apple__ above, we would use:
 
 [source,groovy]
 ----


Mime
View raw message