On 14.10.20 17:01, Anton Shepelev wrote:
Jochen Theodorou to Anton Shepelev:
[...]
Frankly... for years we have been defending this position,
but now, with so much distance I actually really wonder
why we keep this.
Perhaps it would have helped if you had documented not only
language features but also their rationale (justification),
at least is difficult, debatable cases.
the reason is easy: it reflects the implementation. But the
implementation can be changed
[...]
it is actually less the assignment operator itself, it is
the effect of scopes of dynamic variables. To compare.. in
Java you have a static scope for a variable.
But I do not know Java and am learning Groovy as a stand-
alone language, not as a Java derivative.
Sure, any other language you know ;) Python for example has a different
variable scoping system. But most static languages have something like
those static variable scopes.
The compiler knows at any time where a variable is
declared, and where to write it to (local variable or
class). In Groovy we also have the static variable scopes,
but they are "extended" in dynamic Groovy with dynamic
variables. This means the (meta) class is "asked" for the
value and existence of a variable at runtime as soon as we
leave the static scope.
Somewhat similar to metatables in Lua, isn't it?
I never worked with Lua, but from what I have seen I would answer yes.
Why does
not the same thing work from class methods, even from static
class methods? --
class Boo {
static def boo()
{ x = 1
}
}
It does work, only a class does not have the special implementation
Script has.
class AlwaysAnswer{
def getProperty(String something){ 42 }
def ask(question){ return answer }
}
def alwaysAnswer = new AlwaysAnswer()
assert alwaysAnswer.answerToMeaningOfLife == 42
assert alwaysAnswer.myName == 42
assert alwaysAnswer.ask("Are you kidding me?") == 42
The class AlwaysAnswer is a real class and exists additionally to the
class we generate for the script itself. You will see that the code
above does not throw any exception, that is because I implemented the
getProperty method, which is used by the meta class system to answer
when asked for an unknown property. For a static method/property we have
something too:
https://docs.groovy-lang.org/latest/html/documentation/core-metaprogramming.html#_static_propertymissing
If you look at
https://github.com/apache/groovy/blob/master/src/main/java/groovy/lang/Script.java#L54
you see that the class Script does implement getProperty method. Script
is normally used as base class for all Groovy scripts. My example above
for example will generate code like this:
class AlwaysAnswer{
def propertyMissing(String something){ 42 }
def ask(question){ return answer }
}
class Scrip1243324 extends groovy.lang.Script{
void run() {
def alwaysAnswer = new AlwaysAnswer()
assert alwaysAnswer.answerToMeaningOfLife == 42
assert alwaysAnswer.myName == 42
assert alwaysAnswer.ask("Are you kidding me?") == 42
}
}
It is now possible to let the Groovy compiler use a different base class
for scripts, in which case the runtime behaviour changes and you could
let it disallow those global variables - or allow read before write. Or
the script defines overwrites the getProperty method and defines this
kind of behaviour itself.
[...]
In another reply, Maarten Boekhold refers to section 3.4
(Variables) of the "Program structure" document, which has
the following to say about assignments to undeclared (or
undefined?) variables:
if the variable is undeclared, it goes into the script
binding. The binding is visible from the methods, and is
especially important if you use a script to interact with
an application and need to share data between the script
and the application.
I think you should read the whole chapter 3
http://groovy-lang.org/structure.html#_scripts_versus_classes Otherwise
you miss out on some of the concepts and I think this passage alone then
makes much less sense. On the other hand Maarten really explain most of
that already in his mail
The explanation is OK, but I failed to look into that
document. Do you think you can provide better documentation
at a better place? If so, I should certainly appreciate it.
I also thank Maarten for reply.
A better place? What was wrong?
bye Jochen
