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 ded18e0c30 minor wording tweak
ded18e0c30 is described below
commit ded18e0c3001866bca53c592d6acc35f3e40ff0c
Author: Paul King <pa...@asert.com.au>
AuthorDate: Sat May 31 16:42:24 2025 +1000
minor wording tweak
---
src/spec/doc/_type-checking-extensions.adoc | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/spec/doc/_type-checking-extensions.adoc
b/src/spec/doc/_type-checking-extensions.adoc
index ccef4de5f7..334cecaeac 100644
--- a/src/spec/doc/_type-checking-extensions.adoc
+++ b/src/spec/doc/_type-checking-extensions.adoc
@@ -1048,7 +1048,7 @@ Fixing this is very easy and just implies replacing the
`newMethod` call with so
-------------------------------------
include::../test-resources/robotextension3.groovy[tags=example_robot_extension,indent=0]
-------------------------------------
-<1> tell the compiler that the call should be make dynamic
+<1> tell the compiler that the call should be made dynamic
The `makeDynamic` call does 3 things:
@@ -1056,18 +1056,17 @@ The `makeDynamic` call does 3 things:
* automatically sets the `handled` flag to `true` for you
* but also marks the `call` to be done dynamically
-So when the compiler will have to generate bytecode for the call to `move`,
since it is now marked as a dynamic call,
-it will fall back to the dynamic compiler and let it handle the call. And
since the extension tells us that the return
+So when it comes time for the compiler to generate bytecode for the call to
`move`, since it is now marked as a dynamic call,
+it falls back to the dynamic compiler and lets it handle the call. And since
the extension tells us that the return
type of the dynamic call is a `Robot`, subsequent calls will be done
statically!
-Some would wonder why the static compiler doesn't do this by default without
an extension. It is a design decision:
-
-* if the code is statically compiled, we normally want type safety and the
best performance
-* if unrecognized variables/method calls are made dynamic, you lose type
safety, but also all support for catching typos
-at compile time!
+Some might wonder why the static compiler doesn't do this by default without
an extension. It is a design decision.
+If the code is statically compiled, we normally want compile-time type safety
and the best performance.
+If unrecognized variables/method calls were automatically made dynamic, you'd
partially lose compile-time type safety.
+Typos and some scenarios of incorrect typing would no longer be caught at
compile time!
In short, if you want to have mixed mode compilation, it *has* to be explicit,
through a type checking extension, so
-that the compiler, and the designer of the DSL, are totally aware of what they
are doing.
+that the compiler, and the designer of the DSL, are totally aware of exactly
when typing rules are relaxed.
`makeDynamic` can be used on 3 kinds of AST nodes:
@@ -1088,13 +1087,13 @@ you from modifying the AST. However, we do not
recommend you to do so, unless yo
designer and well aware of the compiler internals:
* First of all, you would explicitly break the contract of type checking,
which is to annotate,
-and only annotate the AST. Type checking should *not* modify the AST tree
because you wouldn’t be able to
-guarantee anymore that code without the _@TypeChecked_ annotation
+and only annotate the AST. Type checking should *not* modify the AST tree
because you wouldn’t be able to
+guarantee anymore that code without the _@TypeChecked_ annotation
behaves the same without the annotation.
-* If your extension is meant to work with _@CompileStatic_, then you *can*
modify the AST because
-this is indeed what _@CompileStatic_ will eventually do. Static compilation
doesn’t guarantee the same semantics at
-dynamic Groovy so there is effectively a difference between code compiled with
_@CompileStatic_ and code compiled
-with _@TypeChecked_. It’s up to you to choose whatever strategy you want to
update the AST, but probably
+* If your extension is meant to work with _@CompileStatic_, then you *can*
modify the AST because
+this is indeed what _@CompileStatic_ will eventually do. Static compilation
doesn’t guarantee the same semantics at
+dynamic Groovy so there is effectively a difference between code compiled with
_@CompileStatic_ and code compiled
+with _@TypeChecked_. It’s up to you to choose whatever strategy you want to
update the AST, but probably
using an AST transformation that runs before type checking is easier.
* if you cannot rely on a transformation that kicks in before the type
checker, then you must be *very* careful
