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/20 10:35:20 UTC
[groovy-website] branch asf-site updated: Polish documentation
This is an automated email from the ASF dual-hosted git repository.
paulk pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/groovy-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 6afcb57 Polish documentation
new bb3262c Merge pull request #40 from marcwrobel/fix-typos
6afcb57 is described below
commit 6afcb577fb7720a8e06ec760a9716b2ca8b23ec3
Author: Marc Wrobel <ma...@gmail.com>
AuthorDate: Sun Oct 9 19:21:57 2022 +0200
Polish documentation
Fix typos and improve the documentation.
Note that the following words / expressions were preferred :
- sub type -> subtype (more common, see https://docs.oracle.com/javase/tutorial/java/generics/subtyping.html),
- revert back -> revert (simpler, see https://grammarhow.com/revert-back-correct/),
- in/with regards of -> in regard to (incorrect, see https://community.languagetool.org/rule/show/IN_OR_WITH_REGARDS_TO_OF?lang=en&subId=1)
- all of the -> all the (when possible because it is easier to read),
- meta class -> metaclass (incorrect, see https://en.wikipedia.org/wiki/Metaclass).
---
site/src/site/releasenotes/groovy-1.5.adoc | 46 ++++++++--------
site/src/site/releasenotes/groovy-1.6.adoc | 16 +++---
site/src/site/releasenotes/groovy-1.7.adoc | 2 +-
site/src/site/releasenotes/groovy-1.8.adoc | 14 ++---
site/src/site/releasenotes/groovy-2.0.adoc | 18 +++----
site/src/site/releasenotes/groovy-2.1.adoc | 14 ++---
site/src/site/releasenotes/groovy-2.2.adoc | 2 +-
site/src/site/releasenotes/groovy-2.3.adoc | 18 +++----
site/src/site/releasenotes/groovy-2.4.adoc | 2 +-
site/src/site/releasenotes/groovy-2.5.adoc | 12 ++---
site/src/site/releasenotes/groovy-3.0.adoc | 2 +-
site/src/site/releasenotes/groovy-4.0.adoc | 8 +--
site/src/site/releasenotes/groovy-5.0.adoc | 2 +-
site/src/site/wiki/GEP-11.adoc | 62 +++++++++++-----------
site/src/site/wiki/GEP-12.adoc | 8 +--
site/src/site/wiki/GEP-2.adoc | 10 ++--
site/src/site/wiki/GEP-3.adoc | 20 +++----
site/src/site/wiki/GEP-4.adoc | 8 +--
site/src/site/wiki/GEP-6.adoc | 2 +-
site/src/site/wiki/GEP-7.adoc | 2 +-
site/src/site/wiki/GEP-9.adoc | 6 +--
site/src/site/wiki/groovy-release-discussion.adoc | 4 +-
.../wiki/initial-release-process-proposal.adoc | 10 ++--
23 files changed, 144 insertions(+), 144 deletions(-)
diff --git a/site/src/site/releasenotes/groovy-1.5.adoc b/site/src/site/releasenotes/groovy-1.5.adoc
index a8ce51b..ff52330 100644
--- a/site/src/site/releasenotes/groovy-1.5.adoc
+++ b/site/src/site/releasenotes/groovy-1.5.adoc
@@ -365,7 +365,7 @@ Groovy 1.5, and we are going to discover them in the following section.
Apart from the Java 5 features that brought annotations, generics and
enums into Groovy, a new operator finds its way into the language: ?:
the Elvis operator. When you see the operator in question, you will
-easily guessed why it was nicknamed that way - if not, think in terms of
+easily guess why it was nicknamed that way - if not, think in terms of
Smiley. This new operator is, in fact, a shortcut notation for the
ternary operator. How many times are you using the ternary operator to
change the value of a variable if its content is null to assign it some
@@ -418,7 +418,7 @@ Groovy syntax comes closer to the Java syntax after each release, and
more and more Java code is also valid Groovy. The net benefit of this is
that when you begin with Groovy, you can copy and paste Java code in
your Groovy classes, and this should just work as expected. Then, over
-time, as you learn the language, you start throwing away the semi-colons
+time, as you learn the language, you start throwing away the semicolons
which are not mandatory in Groovy, using GStrings (interpolated
strings), or closures, etc. Groovy offers a rather flat learning curve
to Java developers.
@@ -431,7 +431,7 @@ which was more readable. But as the Groovy users regularly asked for
this old construct to be also part of Groovy, the team decided to bring
it back to Groovy.
-With Groovy 1.5, you can either chose the Groovy for / in, or prefer the
+With Groovy 1.5, you can either choose the Groovy for / in, or prefer the
classical for loop:
[source,groovy]
@@ -450,7 +450,7 @@ in loop instead.
With its malleable and concise syntax, and its advanced dynamic
capabilities, *Groovy is an ideal choice for implementing internal
Domain-Specific Languages*. When you want to share a common metaphor
-between subject matter experts and developers, you can leverage Groovy
+between subject-matter experts and developers, you can leverage Groovy
to create a dedicated business language which models the key concept and
business rules of your application. An important aspect of these DSLs is
to make the code very readable, and also easier to write by
@@ -486,7 +486,7 @@ monster.move left: 3.meters, at: 5.mph
Obviously, this is not a big difference, but each statement becomes
closer to real plain English sentences, and removes the usual
-boiler-plate technical code of the host language. This little
+boilerplate technical code of the host language. This little
enhancement of the grammar of the Groovy language gives more options to
the designers of the business DSL.
@@ -513,7 +513,7 @@ classes by cleverly choosing the order of compilation, and when cyclic
dependencies were spanning both languages, you may have hit a ``chicken
and egg'' problem. Fortunately with Groovy 1.5, this is not the case
anymore, and thanks to a contribution from JetBrains, the makers of the
-award winning http://www.jetbrains.com/idea/[Java IDE IntelliJ IDEA], a
+award-winning http://www.jetbrains.com/idea/[Java IDE IntelliJ IDEA], a
``joint'' compiler is available with which you can compile both Groovy
and Java sources together in one go without having to think about
dependencies between classes.
@@ -649,7 +649,7 @@ website].
Although I'm only mentioning the plugin for IntelliJ IDEA, for your
Groovy developments, you don't have to change your habits. You can also
use the Eclipse plugin which is regularly improved by the IBM Project
-Zero developers, or Sun's brand new support of Groovy and Grails in
+Zero developers, or Sun's brand-new support of Groovy and Grails in
NetBeans.
[[Groovy15releasenotes-Performanceimprovements]]
@@ -683,18 +683,18 @@ system, called the MOP (stands for Meta-Object Protocol) that is
responsible for the dispatching logic. Fortunately, this runtime system
is open enough so that people can hook into the system and change its
usual behavior. For each Java class and for each Groovy instance, there
-is an associated meta-class which represents this runtime behavior of
+is an associated metaclass which represents this runtime behavior of
your objects. Groovy offered various ways to interact with the MOP by
-defining custom meta-classes by extending some base class, but thanks to
-the contribution from the Grails project, a groovier kind of meta-class
-is available: the expando meta-class.
+defining custom metaclasses by extending some base class, but thanks to
+the contribution from the Grails project, a groovier kind of metaclass
+is available: the expando metaclass.
Again,code samples are easier to help us understand the concept. In the
-following example, the msg String instance has got a meta-class that we
-can access through the metaClass property. Then we change the meta-class
+following example, the msg String instance has got a metaclass that we
+can access through the metaClass property. Then we change the metaclass
of the *String* class to add a new method called up to the String class,
to have a shortcut notation for the *toUpperCase()* method. To do so, we
-assign a closure to the up property of the meta-class which is created
+assign a closure to the up property of the metaclass which is created
as we assign it the closure. This closure takes no argument (hence why
it starts with an arrow), and we call the *toUpperCase()* method on the
delegate of the closure, which is a special closure variable which
@@ -708,7 +708,7 @@ String.metaClass.up = { -> delegate.toUpperCase() }
assert "HELLO!" == msg.up()
----------------------------------------------------------------------------------------------------------------------
-Through this meta-class, you can query the methods and/or properties
+Through this metaclass, you can query the methods and/or properties
which are available:
[source,groovy]
@@ -737,14 +737,14 @@ if (msg.metaClass.hasProperty(msg, 'bytes')) {
These mechanisms are extensively used in the Grails web framework for
instance to create dynamic finders: no need for DAOs in most
circumstances, as you are able to call a *findByTitle()* dynamic method
-on a Book domain class. Through meta-classes, Grails automatically
+on a Book domain class. Through metaclasses, Grails automatically
decorates the domain classes with such methods. Furthermore, if the
method doesn't exist yet, it will be created and cached on first use.
This can be accomplished by other advanced hooks as explained below.
-Beyond those examples we've seen so far, expando meta-classes also
+Beyond those examples we've seen so far, expando metaclasses also
provide some complementary hooks. Four other kind of methods can be
-added to an expando meta-class:
+added to an expando metaclass:
* *invokeMethod()* lets you intercept all methods calls,
* while *methodMissing()* will be called on last resort only of no other
@@ -752,14 +752,14 @@ method is found.
* *get/setProperty()* intercepts access to all properties,
* whereas *propertyMissing()* is called when no property can be found.
-With expando meta-classes, customizing the behavior of the types of your
+With expando metaclasses, customizing the behavior of the types of your
application becomes easier and can save precious time of development
compared with the previous version of Groovy. Obviously, not everybody
needs to use those techniques, but they can be handy in a number of
situations where you want to apply some AOP (Aspect Oriented Techniques)
to decorate your classes, and when you want to simplify and make more
readable the business code of your application, by removing some
-unnecessary boiler-plate code.
+unnecessary boilerplate code.
[[Groovy15releasenotes-Swingonsteroids]]
== Swing on steroids
@@ -792,13 +792,13 @@ frame.pack()
frame.show()
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [...]
-In the novelties, the Swing builder concept has been extend to provide
+In the novelties, the Swing builder concept has been extended to provide
custom component factories. There are additional modules, not bundled
with Groovy by default, which integrates the Swing components from JIDE
or from the SwingX project into the usual Swing builder code.
Although this topic would deserve a full article, I'm only going to list
-some of the other improvements in this release, for instance, the bind()
+some other improvements in this release, for instance, the bind()
method. Inspired by the beans binding JSR (JSR-295), you can easily bind
components or beans together to have them react upon changes made on
each other. In the following example, the size of the insets of the
@@ -852,7 +852,7 @@ with the enhanced dynamic capabilities, Groovy will let you customize
your business logic by creating embedded Domain-Specific Languages, that
you can easily integrate at the extension points of your application.
The developer experience has progressed significantly through the work
-poured in the tooling support, this is no more a show stopper to the
+poured in the tooling support, this is no more a showstopper to the
adoption of Groovy. Overall, with Groovy 1.5, the goal of simplifying
the life of developers has never been so well fulfilled, and Groovy
should definitely be part of all the Java developers' toolbox.
\ No newline at end of file
diff --git a/site/src/site/releasenotes/groovy-1.6.adoc b/site/src/site/releasenotes/groovy-1.6.adoc
index 5fdbdf5..76509b1 100644
--- a/site/src/site/releasenotes/groovy-1.6.adoc
+++ b/site/src/site/releasenotes/groovy-1.6.adoc
@@ -22,7 +22,7 @@ metaclasses even for POJOs, and runtime mixins
All those improvements and new features serve one goal: *helping
developers be more productive and more agile*, by:
-* Focusing more on the task at hand than on boiler-plate technical code
+* Focusing more on the task at hand than on boilerplate technical code
* Leveraging existing Enterprise APIs rather than reinventing the wheel
* Improving the overall performance and quality of the language
* Enabling developers to customize the language at will to derive their
@@ -297,7 +297,7 @@ the Swing enhancements, and `@Grab` in the section about Grape).
[[Groovy16releasenotes-Singleton]]
=== @Singleton
-Whether the singleton is pattern or an anti-pattern, there are still
+Whether singleton is a pattern or an antipattern, there are still
some cases where we need to create singletons. We're used to create a
private constructor, a `getInstance()` method for a static field or even
an initialized `public static final` field. So instead of writing code
@@ -374,7 +374,7 @@ e.g. maps
Instead of writing a very long Java or Groovy class mimicking this
immutability behavior, Groovy lets you just write an immutable class as
-follow:
+follows:
[source,groovy]
------------------------------------------------------------------
@@ -388,7 +388,7 @@ def c2 = new Coordinates(48.824068, 2.531733)
assert c1 == c2
------------------------------------------------------------------
-All the boiler-plate code is generated at compile-time for you! The
+All the boilerplate code is generated at compile-time for you! The
example shows that to instantiate such immutable coordinates, you can
use one of the two constructors created by the transformation, one
taking a map whose keys are the properties to set to the values
@@ -453,7 +453,7 @@ assert p.pets.contains('Cat')
The internal field created by the compiler for `pets` will actually be a
Soft reference, but accessing `p.pets` directly will return the value
-(ie. the list of pets) held by that reference, making the use of the
+(i.e. the list of pets) held by that reference, making the use of the
soft reference transparent to the user of that class.
[[Groovy16releasenotes-Delegate]]
@@ -665,7 +665,7 @@ use(NumberCategory) {
--------------------------------------------
We have a simplistic and fictive `Distance` class which may have been
-provided by a third-party, who had the bad idea of making the
+provided by a third party, who had the bad idea of making the
class`final` so that nobody could ever extend it in any way. But thanks
to a Groovy Category, we are able to decorate the `Distance` type with
additional methods. Here, we're going to add a `getMeters()` method to
@@ -872,7 +872,7 @@ often interested in monitoring the changes of value of certain UI
elements. For this purpose, the usual approach is to use
JavaBeans `PropertyChangeListener`s to be notified when the value of a
class field changes. You then end up writing this very common
-boiler-plate code in your Java beans:
+boilerplate code in your Java beans:
[source,groovy]
------------------------------------------------------------------------
@@ -1103,7 +1103,7 @@ runtime system, bringing several new capabilities into the mix.
So far, Groovy POGOs (Plain Old Groovy Objects) could have a
per-instance metaclass, but POJOs could only have one metaclass for all
-instances (ie. a per-class metaclass). This is now not the case anymore,
+instances (i.e. a per-class metaclass). This is now not the case anymore,
as POJOs can have a per-instance metaclass too. Also, setting the
metaclass property to null will restore the default metaclass.
diff --git a/site/src/site/releasenotes/groovy-1.7.adoc b/site/src/site/releasenotes/groovy-1.7.adoc
index 16cfe63..da0a859 100644
--- a/site/src/site/releasenotes/groovy-1.7.adoc
+++ b/site/src/site/releasenotes/groovy-1.7.adoc
@@ -152,7 +152,7 @@ scripts, without having to deal with downloading, packaging, or
specifying the classpath yourself. To use Grape, we had to use the @Grab
annotation to ``grab'' a dependency from a repository (Maven’s central
repository, for example). The problem was that annotation had to be
-attached to some allowed elements, ie. the places where annotations can
+attached to some allowed elements, i.e. the places where annotations can
be put in Java. Now, we can put annotations on imports:
[source,groovy]
diff --git a/site/src/site/releasenotes/groovy-1.8.adoc b/site/src/site/releasenotes/groovy-1.8.adoc
index b20e3ee..ca6749e 100644
--- a/site/src/site/releasenotes/groovy-1.8.adoc
+++ b/site/src/site/releasenotes/groovy-1.8.adoc
@@ -591,7 +591,7 @@ assert awesum() == 6
The @PackageScope annotation can be placed on classes, methods or fields
and is used for turning off Groovy’s visibility conventions and
-reverting back to Java conventions. This ability is usually only needed
+reverting to Java conventions. This ability is usually only needed
when using 3rd party libraries which rely on the package scope
visibility. When adding the `@PackageScope` annotation to a field,
Groovy will assign package scope access to the field rather than
@@ -967,7 +967,7 @@ class CustomException extends Exception {}
[[Groovy18releasenotes-WithReadLockandWithWriteLock]]
=== @WithReadLock and @WithWriteLock
-Those two transformations, combined together, simplify the usage of
+Those two transformations, combined, simplify the usage of
`java.util.concurrent.locks.ReentrantReadWriteLock`, are safer to use
than the `synchronized` keyword, and improve upon the `@Synchronized`
transformation with a more granular locking.
@@ -1212,7 +1212,7 @@ not to be
assert poem.readLines().size() == 4
-----------------------------------
-This is particularly useful for multi-line regexs when using the regex
+This is particularly useful for multi-line regexes when using the regex
free-spacing comment style (though you would still need to escape
slashes):
@@ -1258,8 +1258,8 @@ println dollarSlashy
------------------------
This form of string is typically used when you wish to embed content
-that may naturally contains slashes or backslashes and you don’t want to
-have to rework the content to include all of the necessary escaping.
+that may naturally contain slashes or backslashes and you don’t want to
+have to rework the content to include all the necessary escaping.
Some examples are shown below:
* Embedded XML fragments with backslashes:
@@ -1292,7 +1292,7 @@ Previously, triple quote (`'''`) GString required extra escaping, and
the above sequence was illegal for a normal slashy string. Now, ugly
workarounds are not needed.
-* Embedding multi-line regexs when using the regex free-spacing comment
+* Embedding multi-line regexes when using the regex free-spacing comment
style (particularly ones which contain slashes):
[source,groovy]
@@ -1310,7 +1310,7 @@ assert '04/04/1988' == '1988-04-04'.find(dateRegex) { all, y, m, d -> [d, m, y].
assert '10-08-1989' == '1989/08/10'.find(dateRegex) { all, y, m, d -> [d, m, y].join('-') }
-------------------------------------------------------------------------------------------
-So, you can cut and paste most PERL regex examples without further
+So, you can cut-and-paste most PERL regex examples without further
escaping.
* Or Strings which are themselves Groovy code fragments containing
diff --git a/site/src/site/releasenotes/groovy-2.0.adoc b/site/src/site/releasenotes/groovy-2.0.adoc
index 0cbf311..ab78f64 100644
--- a/site/src/site/releasenotes/groovy-2.0.adoc
+++ b/site/src/site/releasenotes/groovy-2.0.adoc
@@ -13,7 +13,7 @@ features in more detail.
Groovy, by nature, is and will always be a dynamic language. However,
Groovy is often used as a "Java scripting language", or as a "better
-Java" (ie. a Java with less boilerplate and more power features). A lot
+Java" (i.e. a Java with less boilerplate and more power features). A lot
of Java developers actually use and embed Groovy in their Java
applications as an extension language, to author more expressive
business rules, to further customize the application for different
@@ -141,7 +141,7 @@ complains about it.** +
[[Groovy20releasenotes-Commontypeconversionsstillallowed]]
==== Common type conversions still allowed
-The static type checker, however, won’t complain for certain automatic
+The static type checker, however, won’t complain about certain automatic
type conversions that Groovy supports. For instance, for method
signatures returning String, boolean or Class, Groovy converts return
values to these types automatically:
@@ -427,7 +427,7 @@ on the Java platform and bringing some additional performance to
Groovy’s dynamic calls. However, unfortunately shall I say, JDK 7 is not
widely deployed in production at the time of this writing, so not
everybody has the chance to run on the latest version. So developers
-looking for performance improvements would not see much changes in
+looking for performance improvements would not see many changes in
Groovy 2.0, if they aren’t able to run on JDK 7. Luckily, the Groovy
development team thought those developers could get interesting
performance boost, among other advantages, by allowing type checked code
@@ -466,7 +466,7 @@ library code writers to help avoid adverse interactions when dynamic
metaprogramming is in use in several parts of the codebase. The dynamic
features available in languages like Groovy are what give developers
incredible power and flexibility but if care is not taken, different
-assumptions can exist in different parts of the system with regards to
+assumptions can exist in different parts of the system in regard to
what metaprogramming features are in play and this can have unintended
consequences. As a slightly contrived example, consider what happens if
you are using two different libraries, both of which add a similarly
@@ -519,9 +519,9 @@ Since day 1 (that was back in 2003 already!) Groovy has had several
syntax enhancements and features on top of Java. One can think of
closures, for example, but also the ability to put more than just
discrete values in switch / case statements, where Java 7 only allows
-Strings in addition. So some of the Project Coin syntax enhancements,
-like Strings in switch, were already present in Groovy. However, some of
-the enhancements are new, such as binary literals, underscore in number
+Strings in addition. So some Project Coin syntax enhancements,
+like Strings in switch, were already present in Groovy. However, some
+enhancements are new, such as binary literals, underscore in number
literals, or the multi catch block, and Groovy 2 supports them. The sole
omission from the Project Coin enhancements is the "try with
resources" construct, for which Groovy already provides various
@@ -574,7 +574,7 @@ more exceptions as we want to handle them in the same way. A workaround
is either to factor out the commonalities in its own method, or in a
more ugly fashion to have a catch-all approach by catching Exception, or
worse, Throwable. With the multi catch block, we’re able to define
-several exceptions to be catch and treated by the same catch block:
+several exceptions to be caught and treated by the same catch block:
[source,groovy]
-----------------------------------------------
@@ -768,7 +768,7 @@ categories. +
+
Say we want to add a greets() method on String, that would greet the
name of the person passed in parameters, so that you could that method
-as follow:
+as follows:
[source,groovy]
-------------------------------------------------------------
diff --git a/site/src/site/releasenotes/groovy-2.1.adoc b/site/src/site/releasenotes/groovy-2.1.adoc
index 76efec5..978b4da 100644
--- a/site/src/site/releasenotes/groovy-2.1.adoc
+++ b/site/src/site/releasenotes/groovy-2.1.adoc
@@ -254,7 +254,7 @@ the link:{DOCS_BASEURL}/html/documentation/#__code_delegatesto_code[@DelegatesT
Static type checking was introduced in Groovy 2.0, but Groovy 2.1 goes
beyond built-in type checks and offers a way to *create type checker
extensions*. This is great news for Groovy scripts, configuration files,
-or Domain-Specific Languages implementations as they can can be "type
+or Domain-Specific Languages implementations as they can be "type
checked" with more advanced, domain-specific rules. As an example, it
would be possible to create a custom DSL type checker that throws
compilation errors when certain verbs of the DSL are not recognized, or
@@ -333,7 +333,7 @@ variable closure is handed over a `VariableExpression`.
The `VariableExpression` is an object directly from Groovy’s AST
(Abstract Syntax Tree). It is a representation of the unresolved
variable expression. The script checks if the variable is named `robot`,
-if this is the case, we lookup a `ClassNode` representing
+if this is the case, we look up a `ClassNode` representing
the `Robot` class, and store the type of that variable back in the AST.
At the end, the `handled` property is set to true, to indicate the type
checker already managed that variable. As a consequence, you won’t get
@@ -388,7 +388,7 @@ a direction which is forbidden and not understood by our robot.
This second example is also interesting in a way that it shows how you
can even add compilation checks on things like literal strings on a
domain-specific level, paving the way for possible checks on sprintf
-strings, on SQL or HQL code in strings, etc, allowing you to go even
+strings, on SQL or HQL code in strings, etc., allowing you to go even
further that what the Java compiler actually checks.
The extension script can make use of various event oriented extension
@@ -510,7 +510,7 @@ accordingly.
=== Alternate notation
In our example above, we annotated our meta-annotation with the
-annotations that are then combined together. But for annotations for
+annotations that are then combined. But for annotations for
which you don’t need to specify arguments, you could have also passed
the names of the annotations to combine as parameters to the annotation
collector:
@@ -740,7 +740,7 @@ abstract class ExchangeRateBaseScript extends Script {
}
--------------------------------------------------------
-The `lookupRate()` method used in our script is declared in the the base
+The `lookupRate()` method used in our script is declared in the base
class, and the two currencies are retrieved via
the `getProperty()` method.
@@ -795,7 +795,7 @@ No such property: PI for class: mathFormula
-------------------------------------------
We need to use `CompilerConfiguration` to do add an `ImportCustomizer`.
-We’ll create ai `mportConfigurer.groovy` script with the content below:
+We’ll create an `importConfigurer.groovy` script with the content below:
[source,groovy]
---------------------------------------------------------------
@@ -827,7 +827,7 @@ groovy --configscript importConfigurer.groovy mathFormula.groovy
If you use the groovy compiler to compile all your classes, one drawback
of the approach above is that the customization applies globally to all
classes that are going to be compiled. You may want to add certain
-default imports only in certain classes (ie. scripts containing math),
+default imports only in certain classes (i.e. scripts containing math),
but you might want to do something different for other classes, like
adding a `@ToString` transformation to all the domain classes of your
application. For that purpose, a new customizer was created,
diff --git a/site/src/site/releasenotes/groovy-2.2.adoc b/site/src/site/releasenotes/groovy-2.2.adoc
index 8afed88..379f3c5 100644
--- a/site/src/site/releasenotes/groovy-2.2.adoc
+++ b/site/src/site/releasenotes/groovy-2.2.adoc
@@ -179,7 +179,7 @@ The @DelegatesTo annotation, introduced in Groovy 2.1 that helps the
type checker, IDEs, tools, to provide better support for DSLs using
closure delegation
strategies, link:https://issues.apache.org/jira/browse/GROOVY-6134[works with generics token types] as well.
-You can tell Groovy that the delegatee is
+You can tell Groovy that the delegate is
of the type of the generics component:
[source,groovy]
diff --git a/site/src/site/releasenotes/groovy-2.3.adoc b/site/src/site/releasenotes/groovy-2.3.adoc
index ce0e923..0c70c30 100644
--- a/site/src/site/releasenotes/groovy-2.3.adoc
+++ b/site/src/site/releasenotes/groovy-2.3.adoc
@@ -24,7 +24,7 @@ to the shiniest version of Groovy!
Groovy 2.3 doesn’t support the new syntax constructs offered by Java 8
(such as lambdas, method references, default methods in interfaces,
-etc), but you can very well already *use the new APIs offered by JDK
+etc.), but you can very well already *use the new APIs offered by JDK
8*, and even *use Groovy closures in lieu of Java 8 lambdas*.
For reference, here are a couple of examples which use Java 8 streams,
@@ -165,7 +165,7 @@ assert b.fly() == "I'm a flying Colibri!"
Traits are compatible with static type checking and compilation, as well
as our usual dynamic behavior. Trait mixed-in methods are actually
-"real" methods (ie. visible from Java as well) and not just dynamic.
+"real" methods (i.e. visible from Java as well) and not just dynamic.
Note however, that not all existing AST transformations are compatible
with traits.
@@ -239,7 +239,7 @@ that you can choose from:
* a simple strategy for creating chained setters
* an external strategy where you annotate an explicit builder class
-while leaving some buildee class being built untouched
+while leaving some _buildee class_ being built untouched
* a default strategy which creates a nested helper class for instance
creation
* and an initializer strategy which creates a nested helper class for
@@ -425,7 +425,7 @@ the link:https://github.com/groovy/groovy-core/pull/260/files[pull request]
for some further hints of the new methods.
You’ll find familiar methods of the Groovy GDK on `File` also available on
-`Path` like these ones:
+`Path` like these:
[source,groovy]
----
@@ -441,7 +441,7 @@ path.readLines()
== Performance improvements
[[Groovy2.3releasenotes-Miscellanousimprovements]]
-=== Miscellanous improvements
+=== Miscellaneous improvements
Various minor *performance improvements across the board*, for static
compilation, the `invokedynamic` backend, as well as "normal"
@@ -455,9 +455,9 @@ performance, making Groovy 2.3’s JSON support usually
*faster than all the JSON libraries* available in the Java ecosystem.
Rick Hightower and Andrey Bleschestov covered the performance gains,
-both in parsing and seralization, in
+both in parsing and serialization, in
a link:http://rick-hightower.blogspot.fr/2014/04/groovy-and-boon-provide-fastest-json.html[benchmarks on Rick’s blog]
-and on link:https://github.com/bura/json-benchmarks[Andrey’s JSON benchmark project on Github].
+and on link:https://github.com/bura/json-benchmarks[Andrey’s JSON benchmark project on GitHub].
The results are impressive, as the *parsing is generally roughly 2x to 4x faster* with Groovy’s new
parsers compared to existing libraries, and *~21x faster than pre-Groovy 2.3 parsing*.
On the serialization front, Groovy’s
@@ -696,7 +696,7 @@ assert config.a.b.c == 2
In addition, the `isSet()` / `hasSet()` combo methods
(link:https://issues.apache.org/jira/browse/GROOVY-4639[GROOVY-4639]) have been
-added so you can double check if a given node of your configuration has
+added so you can double-check if a given node of your configuration has
been defined. Before, whether the node wasn’t defined or containing
`null`, you couldn’t differentiate either case easily.
@@ -824,7 +824,7 @@ particularly one,
a link:https://issues.apache.org/jira/browse/GROOVY-6465[List#sort(Comparable) method], which *conflicted with one of the GDK*,
so we had to remove ours to stay compliant with JDK 8.
-We fixed a link:https://issues.apache.org/jira/browse/GROOVY-6456[race condition in AbstractHttpServler#applyResourceNameMatcher]
+We fixed a link:https://issues.apache.org/jira/browse/GROOVY-6456[race condition in AbstractHttpServlet#applyResourceNameMatcher]
which incurred a small change in behavior. This feature is seldomly used and doesn’t seem to
have impacted users of the Groovy servlet machinery so far.
diff --git a/site/src/site/releasenotes/groovy-2.4.adoc b/site/src/site/releasenotes/groovy-2.4.adoc
index caaee43..f0ef641 100644
--- a/site/src/site/releasenotes/groovy-2.4.adoc
+++ b/site/src/site/releasenotes/groovy-2.4.adoc
@@ -120,7 +120,7 @@ methods have been added like `init()`, `dropRight()`, `takeRight()`
(link:https://issues.apache.org/jira/browse/GROOVY-6867[GROOVY-6867])
* `Iterable` gets `disjoin()`, `minus()` and `toSpreadMap()` methods
(link:https://issues.apache.org/jira/browse/GROOVY-6920[GROOVY-6920])
-* Refinements and concistency for existing collection methods,
+* Refinements and consistency for existing collection methods,
leveraging iterable approaches for stream-like traversals, consistency
for mutation in place vs new collection creation, minor optimizations,
etc. (link:https://issues.apache.org/jira/browse/GROOVY-6945[GROOVY-6945])
diff --git a/site/src/site/releasenotes/groovy-2.5.adoc b/site/src/site/releasenotes/groovy-2.5.adoc
index f6d3641..9a2796a 100644
--- a/site/src/site/releasenotes/groovy-2.5.adoc
+++ b/site/src/site/releasenotes/groovy-2.5.adoc
@@ -37,7 +37,7 @@ to the included classes referenced by the "all" pom
* also note that since the current jars don't comply fully
yet with JDK9+ requirements (e.g. split package requirements)
you may not be able to place the Groovy jars on your module path.
-Instead, place them on the classpath. On-going work for
+Instead, place them on the classpath. Ongoing work for
Groovy 3.0 will address split package issues (see https://issues.apache.org/jira/browse/GROOVY-8647). If the
Groovy "modules" you want to use aren't in the list being rectified for Groovy 3.0, then
you can probably use them on the module path. The Groovy build currently
@@ -371,7 +371,7 @@ It can be used to override how properties are set within the constructor or acce
for instance how `@Immutable` classes are generated.
* `@VisibilityOptions` is a marker annotation used in the context of AST transformations to provide a custom visibility.
One example of its use would be when you want to create a private constructor
-that might perhaps be called only from within a static factory method of the class:
+that might be called only from within a static factory method of the class:
[source,groovy]
----
import groovy.transform.*
@@ -387,8 +387,8 @@ class Person {
}
----
Here using `@TupleConstructor` saves us the effort of writing the typical
-boiler-plate code within the constructor but we don't need to make it public
-but instead use it within our hand-written factory method which can focus
+boilerplate code within the constructor but we don't need to make it public
+but instead use it within our handwritten factory method which can focus
on our particular business logic relevant to that factory method.
[[Groovy2.5releasenotes-AstTransformImprovements]]
@@ -626,7 +626,7 @@ after the next maintenance release but users should migrate away from that class
will be removed from the next major version of Groovy.
* Users of Spock 1.1-groovy-2.4 may find strange ClassCastException errors with some tests, e.g. with `cleanup:`
clauses. Using Spock 1.2-groovy-2.4-SNAPSHOT from the https://oss.sonatype.org/content/repositories/snapshots/
-repo may help but work is on-going to improve Spock support.
+repo may help but work is ongoing to improve Spock support.
* Users combining `final` and `@CompileStatic` or `final` and Spock may see errors from
the final variable analyzer. Work is underway to resolve those error messages.
You may need to temporarily remove the `final` modifier in the meantime.
@@ -707,7 +707,7 @@ For an example Gradle build that works JDK8 through 11, see
link:https://github.com/apache/groovy/blob/master/subprojects/groovy-jaxb/build.gradle[build.gradle]
in the groovy-jaxb subproject.
|===
-Note: The above above steps aren't our final plan in this space. For 2.5.1, we focused just on making
+Note: The above steps aren't our final plan in this space. For 2.5.1, we focused just on making
life better for non-JAXB users using Groovy via Gradle or Maven. For 2.5.2, we hope to make much
of the above details as hidden as possible and certainly hidden for users of the groovy command-line
tools for JDK9+.
diff --git a/site/src/site/releasenotes/groovy-3.0.adoc b/site/src/site/releasenotes/groovy-3.0.adoc
index 9345177..c29f4a1 100644
--- a/site/src/site/releasenotes/groovy-3.0.adoc
+++ b/site/src/site/releasenotes/groovy-3.0.adoc
@@ -2,7 +2,7 @@
:pygments-style: emacs
:icons: font
-Groovy 3.0 comes with a brand new parser (code-named Parrot) and host of other new features and capabilities.
+Groovy 3.0 comes with a brand-new parser (code-named Parrot) and host of other new features and capabilities.
[[Groovy3.0releasenotes-Parrot]]
== Parrot Parser
diff --git a/site/src/site/releasenotes/groovy-4.0.adoc b/site/src/site/releasenotes/groovy-4.0.adoc
index f4665a8..bed8fa8 100644
--- a/site/src/site/releasenotes/groovy-4.0.adoc
+++ b/site/src/site/releasenotes/groovy-4.0.adoc
@@ -137,7 +137,7 @@ def result = switch(i) {
The `\->` and `:` forms cannot be mixed.
-All of the normal Groovy case expressions are still catered for, e.g.:
+All the normal Groovy case expressions are still catered for, e.g.:
[source,groovy]
--------------------------------------
@@ -713,7 +713,7 @@ as a kind of pre-processor similar to https://projectlombok.org/[Lombok] but bac
|===
a| NOTE: _WARNING:_
Not all parts of the compiler and not all AST transforms yet know about `POJO`.
-Your mileage may vary as to whether using this approach will or won't require
+Your mileage may vary whether using this approach will or won't require
the Groovy jars to be on the classpath. While we anticipate some improvements over time
allowing more Groovy constructs to work with `@POJO`, we currently make no guarantees that
all constructs will eventually be supported. Hence the incubating status.
@@ -1099,7 +1099,7 @@ compiler phase remain unchanged.
=== Old parser removal
Groovy 3 introduced the new "Parrot" parser which supports lambdas, method
-references, and numerous other tweaks. In Groovy 3, You could still revert back to the old parser
+references, and numerous other tweaks. In Groovy 3, You could still revert to the old parser
if you wanted. In Groovy 4, the old Antlr2 based parser is removed.
Please use older versions of Groovy if you require the old parser.
@@ -1238,7 +1238,7 @@ link:https://issues.apache.org/jira/browse/GROOVY-6837[GROOVY-6837].
+
[TIP]
====
-To mimick the old behavior: If `b` is not an Object array and you desire an Object
+To mimic the old behavior: If `b` is not an Object array and you desire an Object
array result, then instead of `b + c`, use one of:
* `b.union(c)`
diff --git a/site/src/site/releasenotes/groovy-5.0.adoc b/site/src/site/releasenotes/groovy-5.0.adoc
index 05b504d..510b4d3 100644
--- a/site/src/site/releasenotes/groovy-5.0.adoc
+++ b/site/src/site/releasenotes/groovy-5.0.adoc
@@ -21,7 +21,7 @@ Some features described here as "incubating" may become stable before 5.0.0 fina
== Other improvements
[[Groovy5.0-ongoing]]
-== On-going work
+== Ongoing work
=== Enhanced switch (under investigation)
diff --git a/site/src/site/wiki/GEP-11.adoc b/site/src/site/wiki/GEP-11.adoc
index b2dbd9d..0cc387c 100644
--- a/site/src/site/wiki/GEP-11.adoc
+++ b/site/src/site/wiki/GEP-11.adoc
@@ -39,9 +39,9 @@ But since this is a confusing feature of limited use, it should be removed.
=== Removing automatic list expansion
A method call done with a list that finds no matching method for that list (a method with one parameter of type List,
-Collection, Object, etc), will cause a second method selection iteration. This time the list is "unpacked" and all
+Collection, Object, etc.), will cause a second method selection iteration. This time the list is "unpacked" and all
elements of the list are taken as if the method call had been done with the elements rather than the list.
-Groovy also supports spreading of lists by an syntax element, making this automatic feature not needed.
+Groovy also supports spreading of lists by a syntax element, making this automatic feature not needed.
In fact this can be quite surprising for users and is a problem for performance.
A spread version might be still not good in performance, but at least the user will have
to use an extra symbol and thus have the visual indicator. As of why this feature was originally added is unclear.
@@ -50,7 +50,7 @@ Looking at user code you will find barely intended usages of this. Thus it shoul
=== Changing Safe Navigation to stop evaluation
Currently an expression like a?.b.c will fail if a is null. It will not evaluate b, but it will try to evaluate c on null.
-This defies the intend of safe navigation to avoid a NullPointerException. Thus this should be changed to stop the
+This defies the intent of safe navigation to avoid a NullPointerException. Thus this should be changed to stop the
evaluation of the path expression.
=== User Wish List
@@ -61,7 +61,7 @@ use-construct and that then we will use this instance along with its instance me
* Replacing Introspector by blackdrag +
Not only because of bugs like GROOVY-5019 there should be a replacement of the Introspector
-=== Some of the leading design ideas of this MOP
+=== Some leading design ideas of this MOP
The plan is to orientate us a lot on the open call site caching the JVM provides with invokedynamic.
For this to work all parts of the MOP should no longer be seen as places that do invoke something,
@@ -76,7 +76,7 @@ missing methods, as well as being able to invalidate a cached version and/or to
image:img/mop_2.jpg[image]
-in meta class of x in pseudo code:
+in metaclass of x in pseudocode:
```
cachable = getMethodInterceptor(...)
@@ -91,17 +91,17 @@ as an explanation to the methods:
* getMethodInterceptor +
Extension point for the user to register an interceptor, that will be used for all method calls.
-This is equal what GroovyInterceptable does using invokeMethod, only that in MOP1 the method is directly called.
+This is equal to what GroovyInterceptable does using invokeMethod, only that in MOP1 the method is directly called.
In MOP2 we will instead return a handler that then will do whatever is needed. This can for example be a method
handle to a invokeMethod method if wanted. TODO: define guards
* getFittingMethod +
-Predefined way to select a method through meta class. This method will return an
+Predefined way to select a method through metaclass. This method will return an
object which then can be used to invoke the selected method.
* getMethodMissingHandler +
Extension point for the user to register a handler for missing methods.
The then invoked method is comparable to what methodMissing in MOP1 would be doing.
* MethodMissingException +
-thrown if none of the above methods is bearing a non null result
+thrown if none of the above methods is bearing a non-null result
* storeInCallSite +
Predefined method to store the cachable result of the above process in the call site.
As long as the cached object is valid the above methods will not be called again for this call site.
@@ -110,28 +110,28 @@ Predefined method to do the Initial invocation of the cachable. Subsequent invoc
=== Context Meta Class
-For the MOP2 Groovy will use a system of meta classes with a context element and an always existing default.
+For the MOP2 Groovy will use a system of metaclasses with a context element and an always existing default.
At each call site only one such view will be valid and it will be constant.
-Those views can be used to defined "sealed" meta class, which won't get influenced by outside
-meta classes or to allow for example calling private methods and not allowing them in other cases.
-This makes 3 possible meta class variations currently:
+Those views can be used to defined "sealed" metaclass, which won't get influenced by outside
+metaclasses or to allow for example calling private methods and not allowing them in other cases.
+This makes 3 possible metaclass variations currently:
-* Default meta class +
-Behaves pretty much like what Java allows in regards of method calls (same class private methods are available)
+* Default metaclass +
+Behaves pretty much like what Java allows in regard to method calls (same class private methods are available)
and all meta programming changes are visible
-* Sealed meta class +
-Like the default meta class, but meta programming changes from outside the class are not visible.
+* Sealed metaclass +
+Like the default metaclass, but meta programming changes from outside the class are not visible.
This can be especially useful to library writers.
-* Test meta class (un)sealed +
+* Test metaclass (un)sealed +
Like the two before but with the addition that private members will always be available.
=== Getting a Meta Class
-Because of the concept of context a class does not have one direct meta class that can be generated without its context.
+Because of the concept of context a class does not have one direct metaclass that can be generated without its context.
The call site defines the place of the context. How the context itself is defined is a TODO.
As an implementation strategy it is possible to for example use ClassValue to store a table with the context being a key.
The key would probably have to be available as static information, or as easily computable information.
-Since the resulting meta class could be stored later in the call site object context changes are to be avoided,
+Since the resulting metaclass could be stored later in the call site object context changes are to be avoided,
since it implies the invalidation of the call sites using that context.
=== General dispatch rule for methods (and properties)
@@ -149,7 +149,7 @@ Given those two definitions a method call in A will select the set of method to
A call m() with the SSC A and done on an instance of B (extends A) will be using the methods defined in A, if A has a private m, otherwise the call is done using B.
Calls to Super: +
-A call to super in B extends A will have the SSC B, but for the method selection process the super class of SSC (super(SSC)) will be used. In super calls mutimethods are not visible. Thus we can directly use the meta class super(SSC), but we will dispatch only on the public methods of that meta class.
+A call to super in B extends A will have the SSC B, but for the method selection process the super class of SSC (super(SSC)) will be used. In super calls multimethods are not visible. Thus we can directly use the metaclass super(SSC), but we will dispatch only on the public methods of that metaclass.
=== Module Extension Methods Shadowing Rules
@@ -182,29 +182,29 @@ It would be great if this mechanism be made pluggable.
=== The Realm concept
-In MOP2 a Realm is a tree like structure containing the meta classes.
+In MOP2 a Realm is a tree like structure containing the metaclasses.
There is a root realm, used as default, but there can be any number of lower realms.
-A meta class change is visible in a realm, if the change is done to the meta class in
-the same realm or to a meta class in a higher realm.
-Script execution engines are able to set a realm for example to prevent them changing meta classes they should not change.
-This can be used for unit tests to isolate meta class changes done during the tests as well.
+A metaclass change is visible in a realm, if the change is done to the metaclass in
+the same realm or to a metaclass in a higher realm.
+Script execution engines are able to set a realm for example to prevent them changing metaclasses they should not change.
+This can be used for unit tests to isolate metaclass changes done during the tests as well.
A library can have its own realm (defined through an annotation) to prevent other classes to
leak their changes into that library, while the library can still use a higher realm to make
changes more public visible, if the realm allows that. Realms can have a setting that prevents
code executed from there to make changes to higher realms. Calling a method is always done using
-the meta classes from the current realm, even if the called class then calls other classes using
+the metaclasses from the current realm, even if the called class then calls other classes using
its own realm. A realm is thus not thread local structure, it is more of a lexical scope.
-A realm can also use a different meta class flavor, to for example allow access to private methods and fields.
+A realm can also use a different metaclass flavor, to for example allow access to private methods and fields.
=== Work Items
This part is to guide the implementors with the course of action and planning of the subtasks.
* make indy the only compilation target in the build
-* move all non-indy bytecode interfacing code to a module, which may be removed later. This includes ScriptBytecodeAdpater as well as all the custom call site caching classes
+* move all non-indy bytecode interfacing code to a module, which may be removed later. This includes ScriptBytecodeAdapter as well as all the custom call site caching classes
* make a new module for MOP2
-* turn meta class into an immutable
-* implement meta class views
+* turn metaclass into an immutable
+* implement metaclass views
=== Breaking changes trace
@@ -262,7 +262,7 @@ Differences to groovy.mop.internal.DefaultMetaProperty:
=== Reference implementation
* https://github.com/groovy/groovy-core/tree/GROOVY_3_FEATURE[GROOVY_3_FEATURE] +
-feature branch on github
+feature branch on GitHub
== Update history
diff --git a/site/src/site/wiki/GEP-12.adoc b/site/src/site/wiki/GEP-12.adoc
index 1009893..3409200 100644
--- a/site/src/site/wiki/GEP-12.adoc
+++ b/site/src/site/wiki/GEP-12.adoc
@@ -22,9 +22,9 @@ A SAM type is an abstract class or interface with a single abstract method.
SAM coercion involves transforming a
`groovy.lang.Closure` instance into an object suitable for our SAM type.
The coercion can happen as part of an assignment or as the result of a method call.
-Since this transformation might be outside of the types provided by Closure itself,
+Since this transformation might be outside the types provided by Closure itself,
it can be more than a simple Java style cast.
-Closure becomes a kind of sub type to all SAM types.
+Closure becomes a kind of subtype to all SAM types.
Groovy has other such transformations without explicit cast or asType usage,
which are number object transformations as well as the conversion of GString to String.
@@ -87,7 +87,7 @@ abstract class SAM {
}
```
-* abstract class with a abstract and a non abstract method:
+* abstract class with an abstract and a non-abstract method:
```
abstract class SAM {
@@ -218,7 +218,7 @@ found here: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/F.html
=== Reference implementation
-* https://github.com/groovy/groovy-core/commits/SAM (feature branch on github)
+* https://github.com/groovy/groovy-core/commits/SAM (feature branch on GitHub)
=== JIRA issues
diff --git a/site/src/site/wiki/GEP-2.adoc b/site/src/site/wiki/GEP-2.adoc
index 3ab12bf..7f82a23 100644
--- a/site/src/site/wiki/GEP-2.adoc
+++ b/site/src/site/wiki/GEP-2.adoc
@@ -99,11 +99,11 @@ def statementBlock = builder.buildFromCode (CompilePhase.CONVERSION, true) {
```
* Expressing Groovy source within Groovy source seems the most natural way to write it (as opposed to putting Groovy source into a String).
-* Some IDE support is naturally available (highlighting, etc), but IDE warnings will be misleading for variable scoping rules
+* Some IDE support is naturally available (highlighting, etc.), but IDE warnings will be misleading for variable scoping rules
* Same issues and rules from "ASTNode from String" for phase and statementsOnly properties apply to this version
* Provides similar API as builder from String, except the code property accepts any block of code that is legal in the context of a Closure.
* Converting from a closure into AST is performed through a global compiler transformation.
-This requires that the AstBuilder reference be strongly typed so that the global annotation can be triggered.
+This requires the AstBuilder reference to be strongly typed so that the global annotation can be triggered.
The above example produces the following AST:
@@ -119,7 +119,7 @@ BlockStatement
==== Alternatives
-If @ASTSource annotation is used, then it would be very easy to let users reuse that annotation outside of the builder.
+If @ASTSource annotation is used, then it would be very easy to let users reuse that annotation outside the builder.
Consider the following example:
@@ -130,7 +130,7 @@ List<ASTNode> source = { println "compiled on: ${new Date()}" }
This option seems helpful; however, annotations on local variables are not yet supported. This approach will not be implemented.
-=== ASTNode from psuedo-specification
+=== ASTNode from pseudo-specification
Building AST conditionally, such as inserting an if-statement or looping, is not easily accomplished in the String or code based builders.
Consider this example:
@@ -203,7 +203,7 @@ https://en.wikipedia.org/wiki/Template_Haskell[Template Haskell]
https://web.archive.org/web/20090213045341/http://blogs.codehaus.org:80/people/bamboo/archives/001593_boo_meta_methods.html[Boo meta methods]
-https://github.com/cython/cython/wiki/enhancements-metaprogramming[Cython Metaprogramming Proposal] by Martin C Martin - Contains nice write up of some use cases
+https://github.com/cython/cython/wiki/enhancements-metaprogramming[Cython Metaprogramming Proposal] by Martin C Martin - Contains nice write-up of some use cases
=== JIRA issues:
diff --git a/site/src/site/wiki/GEP-3.adoc b/site/src/site/wiki/GEP-3.adoc
index d38fcfe..d2170ab 100644
--- a/site/src/site/wiki/GEP-3.adoc
+++ b/site/src/site/wiki/GEP-3.adoc
@@ -111,13 +111,13 @@ commas if multiple arguments are used. A case that is not supported today anyway
* A command-expression is composed of an even number of elements
* The elements are alternating a method name, and its parameters (can be named and non-named parameters)
-* A parameter element can be any kind of expression (ie. a method call foo(), foo{}, or some expression like x+y)
-* All those pairs of method name and parameters are actually chained method calls (ie. send "hello" to "Guillaume"
+* A parameter element can be any kind of expression (i.e. a method call foo(), foo{}, or some expression like x+y)
+* All those pairs of method name and parameters are actually chained method calls (i.e. send "hello" to "Guillaume"
is two methods chained one after the other as send("hello").to("Guillaume"))
==== Interesting benefit of the enhanced command expressions
-More and more do we see Java Fluent APIs that chain method calls, returning this, so as to "build" a new object.
+More and more do we see Java Fluent APIs that chain method calls, returning this, to "build" a new object.
For instance, you can imagine a fluent API for building an Email message, that would look something like this in Java:
```
Email.from("foo@example.com").to("bar@example.com").subject("hello").body("how are you?")
@@ -136,7 +136,7 @@ SELECT "column_name"
FROM "table_name"
WHERE "column_name" IN ('value1', 'value2', ...)
```
-In current Groovy this could maybe expressed by
+In current Groovy this could be expressed by
```
sql.select(
"column_name",
@@ -152,13 +152,13 @@ sql.
where "column_name" \\
in ['value1','value2',...]
```
-It should be noticed, that both cases have quite different semantics. In the second case the writer saves a lot of commas, but of course not all of them. Also the lack of any kind of operator like the comma makes it diifivult to span the DSL across multiple lines. A more extended example would be
+It should be noticed, that both cases have quite different semantics. In the second case the writer saves a lot of commas, but of course not all of them. Also the lack of any kind of operator like the comma makes it difficult to span the DSL across multiple lines. A more extended example would be
```
SELECT COUNT("column_name")
FROM "table_name"
sql.select count("column_name") from "table_name"
```
-To express this in map style is a bit difficult, because of where to place count... a possible version is mabye
+To express this in map style is a bit difficult, because of where to place count... a possible version is maybe
```
sql.select(sql.count("column_name"), from:"table_name"
```
@@ -191,7 +191,7 @@ marinate 30.minutes at roomTemperature
==== Extension to command expressions in the case of assignments
-Currently, command expressions are allowed as standalone top-leval statements or expressions, but you can't assign such an expression to a variable with keeping that nice DSL syntax. For instance, while you can do:
+Currently, command expressions are allowed as standalone top-level statements or expressions, but you can't assign such an expression to a variable with keeping that nice DSL syntax. For instance, while you can do:
```
move left
```
@@ -211,7 +211,7 @@ For historic reasons
```
println foo
```
-has to be supported. This seems to not to be a valid version in Scala, since that would be interpreted as
+has to be supported. This seems not to be a valid version in Scala, since that would be interpreted as
```
println.foo
```
@@ -227,7 +227,7 @@ is interpreted as
```
foo.bar(a1)
```
-in Scala and is invalid in current Groovy as well as after this proposal. So it could be stated, that this proposal is less object oriented then Scala, because the DSL usually starts with the method, not the object. On the other hand it is possible to write
+in Scala and is invalid in current Groovy as well as after this proposal. So it could be stated, that this proposal is less object-oriented then Scala, because the DSL usually starts with the method, not the object. On the other hand it is possible to write
```
foo.bar a1
```
@@ -236,7 +236,7 @@ So the Groovy notation would be a bit more verbose, but not much.
==== To be evaluated: Mixed case with explicit parentheses
A possible supported case is also when mixing method calls with explicit parentheses within that extended command expression.
-The benefit would be to allow the ability to also be able to call methods not taking parameters, as well as allowing an odd number of "elements" (ie. a method name or a parameter).
+The benefit would be to allow the ability to also be able to call methods not taking parameters, as well as allowing an odd number of "elements" (i.e. a method name or a parameter).
```
m1 a m2 b m3()
m1 a m2() m3 b
diff --git a/site/src/site/wiki/GEP-4.adoc b/site/src/site/wiki/GEP-4.adoc
index 8cd5b4c..3703198 100644
--- a/site/src/site/wiki/GEP-4.adoc
+++ b/site/src/site/wiki/GEP-4.adoc
@@ -19,7 +19,7 @@
== Abstract
The AstBuilder was introduced in Groovy 1.7 as a way to ease the task of writing AST transformations.
-The "fromCode" approach allows you generate the AST from a piece of code. Currently, the AstBuilder fromCode API
+The "fromCode" approach allows you to generate the AST from a piece of code. Currently, the AstBuilder fromCode API
accepts a closure as a parameter, and the code within the closure it transformed to AST.
A limitation of the AstBuilder is that the closure parameter does not allow variables in the surrounding
context to be referenced: there is no way to pass a parameter into the code block.
@@ -89,11 +89,11 @@ There are many syntax alternatives:
* Lisp uses ´ and ,
* Template Haskell uses something similar to oxford brackets but with slightly different semantics
-* Boo uses uses GEP 4 - AstBuilder AST Templates and $ but with slightly different semantics
+* Boo uses GEP 4 - AstBuilder AST Templates and $ but with slightly different semantics
A $ was considered but cannot be used as it is already a meaningful identifier.
-Boo Meta Method Comparison
-The Boo Metamethod feature overlaps with the Groovy AST Transformation features. Instead of an @AstTransformation interface with a seperately defined AstTransformation subclass, Boo offers Meta methods, where the AST Transformation is called and generated at compile time.
+Boo Metamethod Comparison
+The Boo Metamethod feature overlaps with the Groovy AST Transformation features. Instead of an @AstTransformation interface with a separately defined AstTransformation subclass, Boo offers Meta methods, where the AST Transformation is called and generated at compile time.
While Groovy offers AstBuilder to turn code into AST, Boo uses the oxford brackets. And while GEP-4 proposed oxford brackets to signify an AST variable templating, Boo uses the $. Consider a simple println AST in Groovy
```
diff --git a/site/src/site/wiki/GEP-6.adoc b/site/src/site/wiki/GEP-6.adoc
index 103abc1..63fc9a3 100644
--- a/site/src/site/wiki/GEP-6.adoc
+++ b/site/src/site/wiki/GEP-6.adoc
@@ -36,7 +36,7 @@ then we risk having JDK7 make an API change, which would force us to support 2 d
=== Todo in Groovy NIO Module:
* Support new Path object
-* All of the GDK File API needs to be on Path
+* All the GDK File API needs to be on Path
* NIO2 contains a new WatchService API. We need to probably provide a GDK on WatchService to make it easy to work
with using closures, etc. This is the most interesting piece of work IMO.
diff --git a/site/src/site/wiki/GEP-7.adoc b/site/src/site/wiki/GEP-7.adoc
index a408bcc..60c1d11 100644
--- a/site/src/site/wiki/GEP-7.adoc
+++ b/site/src/site/wiki/GEP-7.adoc
@@ -72,7 +72,7 @@ println builder.toString()
```
Valid node values are: `Number`, `String`, `GString`, `Boolean`, `Map`, `List`. `null` is reserved for object references.
-Arrays can not be null but they can be empty. Anything else results in an IAE (or a more specialized exception) being thrown.
+Arrays can not be null, but they can be empty. Anything else results in an IAE (or a more specialized exception) being thrown.
=== Special cases
diff --git a/site/src/site/wiki/GEP-9.adoc b/site/src/site/wiki/GEP-9.adoc
index 63cf201..cfe229f 100644
--- a/site/src/site/wiki/GEP-9.adoc
+++ b/site/src/site/wiki/GEP-9.adoc
@@ -42,7 +42,7 @@ After modularization, the main Groovy codebase will be packaged into additional
* groovy.jar or groovy-core.jar (name to be finalized) will contain a smaller set of core classes for Groovy and will retain its dependency on a small handful of critical dependent jars (i.e. asm, antlr, etc.)
* numerous smaller "module/component" jars (exact names/numbers/contents to be finalized) but possibly things like groovy-bsf.jar, groovy-sql.jar, groovy-swing.jar, groovy-jmx.jar, groovy-xml, groovy-tools etc.
-* groovy-all.jar contains the core classes for Groovy, bundled versions of the critical dependent jars and all of the classes from the module jars
+* groovy-all.jar contains the core classes for Groovy, bundled versions of the critical dependent jars and all the classes from the module jars
* optionally we may support other "profiles" - profiles being other "fat" jars we bundle together for other environments, e.g. groovy-android.jar might exclude the JMX or Swing modules for instance.
Recommendations/suggestions for jar groupings are welcome. See some more details in the accompanying discussion: Groovy 2.0 modularization.
@@ -109,14 +109,14 @@ m| META-INF/services/groovy/defaultExtensions | allow the module to define suppo
m| META-INF/services/groovy/defaultAstTransforms | allow the module to define AST transforms | now in `META-INF/services/ +
org.codehaus.groovy.transform.ASTTransformation`
| ? | provide a way to register builder metadata | deferred
-| ? | should there by a way to 'publish' new commandline level startup scripts e.g. java2groovy | deferred
+| ? | should there be a way to 'publish' new commandline level startup scripts e.g. java2groovy | deferred
| ? | provide a way to register a runner class, e.g. EasyB - there might also be a need to detect runner types | now in `META-INF/groovy/ +
org.apache.groovy.plugin.GroovyRunner`
| ? | provide a way to register special compiler flags, e.g. '--indy' | deferred
| ? | provide a way to inject special AST customizations | deferred
|===
-This is also where we could specify additional requirements, e.g. require 'invoke dynamic' - but see later also. Could we declaratively specify our security policy requirements. Or can we disable specific aspects of functionality, e.g. disable some standard global AST transform because we want to provide a better one. (There are obviously security implications for this!)
+This is also where we could specify additional requirements, e.g. require 'invoke dynamic' - but see later also. Could we declaratively specify our security policy requirements? Or can we disable specific aspects of functionality, e.g. disable some standard global AST transform because we want to provide a better one? (There are obviously security implications for this!)
Another question is whether all these features will be available also via an API. Would such an API allow modules to be "unregistered"?
diff --git a/site/src/site/wiki/groovy-release-discussion.adoc b/site/src/site/wiki/groovy-release-discussion.adoc
index 84d9ca0..af7753a 100644
--- a/site/src/site/wiki/groovy-release-discussion.adoc
+++ b/site/src/site/wiki/groovy-release-discussion.adoc
@@ -65,7 +65,7 @@ The release plan is at the core of the Groovy release process. It reduces human
* Maven Central synchronization is done through the {bintray} API
* GVM gets notified that a new version is available
-To do this, the only requirement is to fill in a form and click a button. From that, everything is automated. So when the Groovy team decides that a new release can be done, after clicking the button, the release is available online in general less than 2 hours later. This has to be compared to the previous, error prone process, which took up to 12 hours for a single release. Groovy has a tradition of maintaining multiple branches, so this time has to be multiplied by the number of activ [...]
+To do this, the only requirement is to fill in a form and click a button. From that, everything is automated. So when the Groovy team decides that a new release can be done, after clicking the button, the release is available online in general less than 2 hours later. This has to be compared to the previous, error-prone process, which took up to 12 hours for a single release. Groovy has a tradition of maintaining multiple branches, so this time has to be multiplied by the number of activ [...]
With that regards, the decision whether to release a new version or not is done collectively, on the mailing list or in a Skype channel where the core developers agree about releases. But once the decision is made, there is almost no human process involved anymore.
@@ -102,7 +102,7 @@ _We're all clear on that. Groovy is tested before each release, and the CI serve
* 3.1 DISCLAIMER is correct, filenames include "incubating".
-_We need to add the *DISCLAIMER*. The "incubating" part is disturbing. In particular, Groovy is not a new project. It has been around for 12+ years, and the last release before Apache will be 2.4.2. Does it mean that the next release will have to be named 2.4.3-incubating? It will be very disturbing for our users, and it sounds pretty bad, just as if Groovy wasn't production ready. Should we do this, then the incubation phase should be shortened as much as possible. Another option that w [...]
+_We need to add the *DISCLAIMER*. The "incubating" part is disturbing. In particular, Groovy is not a new project. It has been around for 12+ years, and the last release before Apache will be 2.4.2. Does it mean that the next release will have to be named 2.4.3-incubating? It will be very disturbing for our users, and it sounds pretty bad, just as if Groovy wasn't production ready. Should we do this, then the incubation phase should be shortened as much as possible. Another option that w [...]
* 3.2 Top-level LICENSE and NOTICE are correct for each distribution.
diff --git a/site/src/site/wiki/initial-release-process-proposal.adoc b/site/src/site/wiki/initial-release-process-proposal.adoc
index 85ec6a7..e3f1785 100644
--- a/site/src/site/wiki/initial-release-process-proposal.adoc
+++ b/site/src/site/wiki/initial-release-process-proposal.adoc
@@ -16,7 +16,7 @@ If any of the steps in the automated process fail, this documentation might prov
== Background
-The goal of this document is to guide the release manager in order to perform a release under the Apache Incubator. This document, reflecting the status of incubation, is work in progress and will be adapted with regards to comments from the community, mentors and IPMC.
+The goal of this document is to guide the release manager in order to perform a release under the Apache Incubator. This document, reflecting the status of incubation, is work in progress and will be adapted in regard to comments from the community, mentors and IPMC.
== Initiating a release
@@ -42,7 +42,7 @@ git push origin GROOVY_2_4_X
If you haven't done it already, create a token on https://github.com/settings/tokens[your GitHub profile] so that the CI server can have write access on your fork. Keep the token safe!
-== Setup the TeamCity release configuration
+== Set up the TeamCity release configuration
Go to the http://ci.groovy-lang.org/admin/editBuild.html?id=buildType:Groovy_BintrayIntegration_ReleasePlan[TeamCity release plan] configuration and open the VCS settings. If the VCS root attached to the configuration is not your GitHub fork, attach your VCS root, or create a new VCS root if you haven't done it already. The VCS root MUST have write access using the token authentication.
@@ -57,7 +57,7 @@ Go to the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayInte
* _groovyBundleVersion_
** _release version_ must be set to the OSGi bundle version number of Groovy you are releasing. For example `2.4.6`.
** _next integration version_ *must* be set to the subsequent OSGi bundle version number of Groovy you are releasing and as it will be a development version, *must* end with `.SNAPSHOT`. For example `2.4.5.SNAPSHOT`.
-* _Checkout branch:_ must be set to the branch your are releasing. For example, if you are releasing a 2.4.x version of Groovy, `GROOVY_2_4_X`.
+* _Checkout branch:_ must be set to the branch you are releasing. For example, if you are releasing a 2.4.x version of Groovy, `GROOVY_2_4_X`.
* _Use release branch_ must be checked, and it will automate the creation of a release branch. Use a branch name in the form of `REL_BRANCH_2_4_3`
* _Create VCS tag_ must be checked, and it will automate the creation of a release tag. Use a tag name in the form of `GROOVY_2_4_4`
* _Tag comment_ must be set to something useful describing the release version
@@ -213,7 +213,7 @@ in the `groovyVersion` parameter. Click on `run build`.
* if the release is NOT a beta or a release candidate, make it the default version on GVM. Open http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmMakeDefault[the GVM make default configuration], click on the 3 dots near `run` then on the _parameters_ tab, fill
in the `groovyVersion` parameter. Click on `run build`.
-== Update the web site
+== Update the website
If you don't have it locally, checkout `https://github.com/groovy/groovy-website`.
@@ -224,7 +224,7 @@ If you don't have it locally, checkout `https://github.com/groovy/groovy-website
== Send an announcement email
You should wait 24h before doing this (in order for `dist.apache.org` to be properly mirrored).
-Send an email to `dev@`, `user@` and `announce@apache.org`.
+Email `dev@`, `user@` and `announce@apache.org`.
You can use this template. Please make sure that the email at least contains the DISCLAIMER: