r example, why would Person::validate be dangling under
static compilation ? Is it "just" that at the point in time when the
Groovy compiler tries to process Person::validate, it is not yet
resolved/resolvable ? Would that also mean it would currently not work
under @TypeChecked ?
Ch
Hi Paul,
Grails has been an important part of the Groovy ecosystem for a long
time, so Groovy sponsoring them joining the ASF seems to make sense to
me... G-)
Cheers,
mg
On 11/07/2024 07:09, Paul King wrote:
Hi folks,
The Grails project is wanting to enter the ASF. They have two paths
, it still seems like an
academic problem to me.
Cheers,
mg
On 01/05/2024 23:37, Paul King wrote:
if this is to be supported, I would still argue for the more general approach.
Both potential tweaks that I looked at did use the more general approach.
like that.
4. ...and this is coming from someone who is big on static typing &
type checks where possible, for readability and avoiding some
trivial runtime errors :-)
Cheers,
mg
On 01/05/2024 13:40, Paul King wrote:
Just to come back to this discussion. The existing functionality is
what
ator and equals could maybe be supplied
in a TypeCheckingExtension sub-class or a helper class... (?)
Cheers,
mg
On 08/04/2024 15:28, Jochen Theodorou wrote:
Our options seem to be:
(1) not trying to make this work
(2) modify operators to method call expressions earlier (might remove
have a look at on your
own, asking on the mailing list if a question arises - or maybe
someone has the time & knowledge to guide you... G-)
Cheers,
mg
On 25/03/2024 21:38, Caleb Brandt wrote:
But uh, the biggest thing is that I want to spend my summer working on
a passion project w
enticing new features - it is not about fooling
people into believing that they are still using Java, it is about them
realizing how many cool treasures lie on the other side of the fence,
and no language can make that easier with regards to Java than Groovy G-)
Cheers,
mg
On 25/03/2024 16:34, O
Gradle, Maven, etc you will have to check where the
file needs to go.
Cheers,
mg
On 01/03/2024 23:30, Videla, Gabriel wrote:
Thanks MG and Jochen for your explanations.
If we manage to identify the part of our code with the performance
issue we'll let you know.
you can switch
that creatings so many objects is
actually a bug ;-)
9. On the Groovy side of things there was some activity on this a short
while ago, and I am also waiting on some update, to see if we will
be able to go back to our older, more convenient implementation... :-)
Cheers,
mg
On 23/02/
I have created https://issues.apache.org/jira/browse/GROOVY-11291 for
this topic
@OZ: Please feel free to add your angle to the ticket G-)
Cheers,
mg
On 18/01/2024 23:18, MG wrote:
Hi Jochen,
1. For our case we would not need to have obsolete class files to be
deleted, just
for small collect/forEach closures ?).
Cheers,
mg
On 16/01/2024 12:42, Jochen Theodorou wrote:
Am 15.01.24 um 20:24 schrieb o...@ocs.cz:
Jochen,
On 15. 1. 2024, at 10:35, Jochen Theodorou wrote:
If the goal is to give Groovyc a source file and let it compile that,
but write only
roovyc who decides to
recreate all those auto-generated closure classes... (?)
Cheers,
mg
On 14/01/2024 14:04, Jochen Theodorou wrote:
On 12.01.24 18:50, MG wrote:
Hi guys,
is there a way to get Groovy not to nedlessly recreate closure class
files during a build which would otherwise just
to continuously
rsync-upload these files to the server after small code changes becomes
a factor in turnaround time...
Cheers,
mg
ld also support Jochen's idea from above, and
suggest the user use that to avoid the BigDecimal fallback
in a warning ;-) )
Cheers,
mg
On 10/01/2024 14:57, Paul King wrote:
On Wed, Jan 10, 2024 at 8:41 PM Jochen Theodorou wrote:
On 10.01.24 05:53, Paul King wrote:
Hi f
I would prefer to see that money to go into advancing Groovy itself, not
paying someone to do some graphic design or such.
Cheers,
mg
On 28/06/2023 08:37, Søren Berg Glasius wrote:
Not a bad idea Daniel, and with all the money FoG has, it could even
be financed.
Med venlig hilsen,
Søren
ave a few days to get the
queries back to acceptable speed, so I will probably actually have to
rip out the traits, add their members to each class by hand and replace
them with interfaces...
Thanks, Cheers,
mg
On 08/05/2023 21:09, Jochen Theodorou wrote:
On 07.05.23 23:05, MG wrote:
H(a|e)llo
olved traits package path I could only see some very
small, trivial interface class files in IntelliJ...
Cheers,
mg
On 07/05/2023 12:40, Jochen Theodorou wrote:
On 07.05.23 00:56, MG wrote:
Hi guys,
we have (a bit of an urgent) performance problem: The SQL generation
part that is an el
e does not need Java Bean spec
compatibility...
Cheers,
mg
On 23/04/2023 17:44, Milles, Eric (TR Technology) via dev wrote:
It is described in GROOVY-9382, GROOVY-10133, GROOVY-10707,
GROOVY-10821 and possibly others.
"""
This was an intentional change for Groovy 4. There wa
say, ChatGPT ?
ChatGPT: "People hold a variety of opinions on this topic. For instance
... "
Cheers,
mg
On 23/03/2023 02:43, Paul King wrote:
Hi folks,
It has been a while but I finally got back around to this issue.
As a reminder, this issue is about using "mod" as
O00, BLP00, BLQ00, BLR00, BLS00, BLT00, BLU00, BLV00,
BLW00, BLX00, BLY00, BLZ00, BMA00, BMB00, BMC00, BMD00, BME00, BMF00,
BMG00, BMH00, BMI00, BMJ00, BMK00, BML00, BMM00};
}
Cheers,
mg
enum MethodTooLargeExceptionEnum {
XXX(-1),
A(0),
B(1),
C(2),
D(3),
E(4)
The enum approach plays well with other (much smaller) enums, gives us
version control, compile time checks & type safe access inside of
Groovy, Groovy logic (e.g. fallback values), Intellisense, and makes the
data easily editable inside IntelliJ (including commenting), so it imho
handily
ntional workaround. We als decided against trying to
use reflection magic to go around these restrictions since it rules out
Intellisense support, for fear of this approach breaking in the future,
etc.)
Cheers,
mg
PS: Evidently Kotlin has introduced a compiler flag to be able to change
the way e
That is exactly what I was thinking: Do not support Java 8 in Groovy 5,
but backport (as has been done in the past) some stuff to
Java8-supporting Groovy 4 G-)
Cheers,
mg
On 27/06/2022 00:04, James Bond wrote:
perhaps an earlier version of Groovy will continue to suffice for them
until
', SqlTypes.VARCHAR(128))
final DATE_OF_BIRTH = new Column(this, 'DATE_OF_BIRTH ', SqlTypes.DATE)
// ...
}
Cheers,
mg
On 10/05/2022 20:09, Jochen Theodorou wrote:
On 09.05.22 22:13, MG wrote:
Hi Jochen,
our code certainly creates a lot of (short lived) class instances*, but
we do
Another question would be, whether anyone here knows whether other
dynamic JVM languages such as Clojure/Jython/JRuby/... are
a) using Indy calls, and
b) are or have been facing similar performance problems... ?
On 09/05/2022 19:53, Jochen Theodorou wrote:
On 09.05.22 17:41, MG wrote:
Hi
the Table.reference(...) calls
from the script code, since these calls use reflection to create the
correct Table instance, to see if that has any influence, but this
leads to the same amount of speedup for Groovy 3 and 4, so the
performance degradation between Grooyv 3 and 4 stays the same at 3x)
Cheers,
mg
the test script interleaved
between Grooyv 3 / 4 multiple times to see how measurements develop,
but I would say it is clear that Groovy 4 is always way slower than
Groovy 3 for this test, and that is all that matters :-)
Cheers,
mg
On 08/05/2022 19:53, Jochen Theodorou wrote
ptimizations with my sample, to confirm that they indeed
lead to the performance Groovy 3 exhibits :-)
Cheers,
mg
On 07/05/2022 18:12, Daniel Sun wrote:
Hi mg,
Groovy 4 enables indy, i.e. invokedynamic by default, and the default threshold for
optimization of indy is 10,000. We
To download all 3 files in a single ZIP, you can use the following URL:
https://github.com/mgroovy/groovyperformance/zipball/master/
Cheers,
mg
evant change in performance.
So this is hoping this finally supplies the information that leads to a
solution to this problem by someone that has knowledge about the inner
workings of Groovy & the JVM invokedynamic mechanism, and un-bars us
from ever switching to Groovy 4 G-)
Cheers,
mg
reference frame in special/general relativity...
I think we made our points, I suggest we wait what Mr. Groovy (aka Paul)
has to say, who might easily shoot this down with an argument no one has
yet considered... G-)
Cheers,
mg
On 18/11/2021 20:40, h...@abula.org wrote:
Well, one example:
) in a general, meaningful, and least surprise way, so that
the result of the comparison makes sense in some useful scenarios,
without carrying too much danger of introducing erronous behavior ?
So:
1. Can it generally be done ?
2. And then, as always, "risk/reward" / "lifeness vs safeness
s. Conflating the two just because it happens to work for
some applications is just bad design imho.
On Thu, 18 Nov 2021 at 17:43, MG wrote:
A day, year, etc is evidently never equal to an actual point in
time, since it is an interval. The question for me is: Can we
convert t
it (wich is the direction I am leaning to) - but convince me otherwise
(saying "it is just wrong on principal" won't do that, though, unless I
buy into your principle, which I oftend do not, since for me what is
relevant is mostly whether it works in practice).
Cheers,
mg
PS: The
, nobody is suggesting you start building your
application mixing Date and DateTime objects for the heck of it, it
would in my eyes just be if you do not control the return value of a
call, legacy reasons, stuff like that.
Cheers,
mg
On 18/11/2021 15:10, Alessio Stalla wrote:
Dates
1. Implicitly attach Time to Date
2. Fill Time with zeroes
3. There you go
On 18/11/2021 15:45, h...@abula.org wrote:
Re. 5:
But there is nothing to fill up with zeroes...
BR;H2
Den 2021-11-18 15:11, skrev MG:
I don't think that is correct: Time intervals for days, etc always
need
convention of
"filling things up with zeroes", if not explicitly told differently
;-) )
Cheers,
mg
*Otherwise a point in time could be in more than one interval (e.g.
belong to more than one day).
On 18/11/2021 14:22, Jochen Theodorou wrote:
On 17.11.21 20:28, MG wrote:
[...]
3. I ha
(or they
can, but then your language of choice is Java, not Groovy), but need to
be evaluated case by case.
Maybe extension methods are enough for the concrete case, but I think we
should still consider if this should not be a general extension to Groovy.
Cheers,
mg
On 18/11/2021 12:35, h
1, 0, 0, 1)]
list.sort(true)
How should list be sorted? 0 and 1 are the same, right. Is 2 greater
than 0 or the same?
*From:* MG
*Sent:* Wednesday, November 17, 2021 1:29 PM
*To:* dev@groovy.apache.org
*Subject:* Re: [EXT] Re: A feature request: comparing LocalDate and
LocalDateTime u
the situation of
making LocalDate and LocalDateTime comparable, since I see very
little chance of bugs being introduced or "least suprise" being
violated by this.
Given these assumptions, I would right now see no harm in supplying this
functionality.
Cheers,
mg
On 17/11/2021
Hmmm, yes, that would be an option.
More terse & can be discovered via Intellisense are two reasons I could
think of that speak for the toList()/toMap() approach...
Cheers,
mg
On 02/11/2021 12:48, OCsite wrote:
Hi there,
I am probably missing something obvious here, but why adding sepa
name seems quite long, maybe we can
come up with something more terse ?
5. toMap(): If we have toList(), would a toMap() make sense, so that
the map could be modified and passed as a record ctor argument to
create a new record ?
Cheers,
mg
On 01/11/2021 16:14, Paul King wrote:
Hi
://github.com/apache/groovy/actions/runs/1375230234, and the
results are basically unchanged (did therefore not upload
screenshots to ticket)
Cheers,
mg
On 26/10/2021 18:02, Daniel Sun wrote:
groovy.indy.callsite.cache.size can control the size of PIC, e.g.
-Dgroovy.indy.callsite.cache.size=4
Also
://issues.apache.org/jira/browse/GROOVY-10307
Cheers,
mg
On 24/10/2021 18:29, Daniel Sun wrote:
What I can tell you for sure is, that invokedynamic has a big problem with
1-time calls. It is much more expensive to generate the callsite for
invokedynamic than it is for our old callsite code (which
Hi Paul & Jochen.
I have uploaded some repeated test execution timings & VisualVM hot spot
screenshots from a suitable looking test, comparing Groovy 3.0.9
(non-INDY) with Groovy 4.0.0-beta-1:
https://issues.apache.org/jira/browse/GROOVY-10307
Cheers,
mg
On 15/10/2021 10:21, P
nger to finish (overall the test suite takes about 120 min
when using G4, compared to about 50 min with G3)
Ticket: https://issues.apache.org/jira/browse/GROOVY-10307
Cheers,
mg
On 14/10/2021 13:32, Paul King wrote:
Hi mg,
Antlr4 performance is something we want to work much
put our focus in analyzing this, to create a test case
independent of our framwork ?
Cheers,
mg
*Groovy 3.0.9 [s]* *Groovy 3.0.9 INDY [s]* *Groovy 4.0.0-beta-1 [s]*
*G3INDY/G3 Ratio* *G4/G3 Ratio*
3038720074402.372.45
160.146 482.584 467.058 3.01
ven
though the input source might have looked a lot like SQL ;-) ).
7. "groovy-q" might be a possible alternative(if we allow one-letter
module names), since "Q" is of course a well known, powerful figure
from the Star Trek universe
(https://en.wikipedia.org/wiki
I have created issues for both of my recent posts:
NPE: Pinpoint Exact Location in Call Chain:
https://issues.apache.org/jira/browse/GROOVY-10258
Groovy4 NV Macros: Rename NV* -> SV*:
https://issues.apache.org/jira/browse/GROOVY-10259
Cheers,
mg
of the (more
flexible/powerful) NV* macro and NameAndValue class to coexist with it.
Cheers,
mg
PS: I would also propose for Groovy to actually support both approaches,
since I see them as orthogonal to each other, serving different
purposes, but that is a different topic G-)
PPS: Here is another example,
to invest any effort here for now,
mg
On 23/09/2021 22:38, Paul King wrote:
Some replies inline.
On Fri, Sep 24, 2021 at 6:03 AM MG <mailto:mg...@arscreat.com>> wrote:
Hi Paul,
I know you do not like them, but that again sounds like a perfect
example for an e.g. &q
ot knowing about the
fact that actual sealed classes require JDK 17.
Cheers,
mg
On 21/09/2021 09:40, Paul King wrote:
For recent features like sealed classes and records*, we are moving
towards implementations which support the feature natively (as per
Java) when compiled with a suitable
)" because the
return value of "simple.groovy.HelpfulNullPointerExceptionTest$D.getC()"
is null ** Would hope for something like (or its pretty-printed
equivalent): java.lang.NullPointerException: Cannot get property
'x.c.b.a' on null object */ x.c =null println"x.c.b.a=$x.c.b.a" }
}
Cheers,
mg
on style seems like a good idea.
4. Definitely Class[] over String[], if doable (using String in these
cases always felt/feels like an ugly hack to me)
Cheers,
mg
On 31/07/2021 08:08, Paul King wrote:
Hi folks,
With JDK17 introducing sealed classes[1] (which has been in preview
for JDK15/16), Groovy
with ambigous ctor GroovyRuntimeError
static createGoo_Works(Goo0 g0 = null) { new Goo((Goo0) g0) }
Goo(Goo0 g0) { ... }
Goo(Goo1 g1) { ... }
}
Cheers,
mg
*Mostly to indicate the use of a default value; this avoids the problem
of having to change a lot of signatures if the default
there (I saw
groovy-2.5.6-indy.jar in the stack trace you posted) ?
(Both versions have basically the same performance characteristics, but
non-indy is much more widely used, and therefore much better tested.)
Cheers,
mg
On 03/05/2021 15:32, Alexander Veit wrote:
Hi,
please give me a hint
.0.7 downloaded from the webpage, so I am
not sure what I am looking at (bug, need to configure
groovy-3.0.0-SNAPSHOT build differently, ...), and therefore how to
debug it.
Cheers,
mg
Groovyc: While compiling [groovymacro]: BUG! exception in phase
'semantic anal
On 06/03/2021 04:06, Paul King wrote:
On Sat, Mar 6, 2021 at 6:55 AM MG <mailto:mg...@arscreat.com>> wrote:
@we'd want the full info somewhere: Agree.
But since the annotation section headers already have the fully
qualified name and the user gets taken there when
@we'd want the full info somewhere: Agree.
But since the annotation section headers already have the fully
qualified name and the user gets taken there when he clicks the
annotation (short) name on the sidebar, so I feel we are good here :-)
Cheers,
mg
On 05/03/2021 20:45, Paul King wrote:
I
in a
glossary-like style as you suggest (from the top of my hat it feels like
you suggestion could also help with mobile rendering of the Groovy
documentation, since it by nature is more vertical than a tabular approach).
What do others think ?
Cheers,
mg
On 03/03/2021 22:01, Leo Gertsenshteyn
special (feels like a quantum superposition), that it
is really easy to work around, once found... ;-)
Cheers,
mg
Forwarded Message
Subject: Re: groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc:
Internal groovyc error: code 1 ?
Date: Wed, 3 Mar 2021 01:07:00 +01
in principle, but I am wondering if
a potential increase in compile time is something we would need to be
worried about here... ?
Cheers,
mg
On 20/01/2021 23:25, Christopher Smith wrote:
I'm open to tinkering on it, but my understanding of the compiler
Internals is extremely limited. If more
can always fit another value between existing ones (by adding another
letter / digit) :-)
Cheers,
mg
On 20/01/2021 08:01, Christopher Smith wrote:
A longstanding shortcoming of the AST-transformation system is the
minimal guarantees provided when multiple ASTTs target the same area
of cod
osure bodies, often single statetments, so there is never any
danger of confusing what the it refers to.
3. This is in my experience absolutely not the case for any larger
piece of code, so let's agree to differ on whether masking variables
in general is a good idea or not :-)
Cheers,
mg
: Both useful, and if it works for for, it should work in similar
places.
Cheers,
mg
and
variables who live throughout a method or larger block I use no number
postfix or longer names; the short name / long name meta at least is
quite common, I think)
Cheers,
mg
On 02/12/2020 18:13, OCsite wrote:
Hello there,
when touching this stuff, it would be extremely desirable
Something along that line, yes :-)
(Just wondering, since you seemed to say in the beginning that you did
not want to create objects (if I read this correctly), why creating
AutoCloseable instances here would not pose a problem ?)
Cheers,
mg
On 23/11/2020 00:45, Milles, Eric (TR Technology
I was primarily referring to what Jochen said about a mixin being a
possible solution: "could be a mixin... but if your requirement is to
avoid the creation of additional objects, then this will not work, as
the Closure will be created new every time.".
But I also looked at your code, and saw
bad, just that the
hurdle for most Groovy devs will be considerably higher)
Cheers,
mg
*It could be abused, yes, but so can many others, and one could make it
abundantly clear in the docu that inlining closures is not a silver
bullet, and you should know what you are doing.
On 22/11/
want to solve in a generic manner...
Cheers,
mg
On 22/11/2020 02:03, Milles, Eric (TR Technology) wrote:
Thanks for the reply. So if I use an AutoCloseable, I would have
something like:
class Foo {
private state
def bar() {
def temp = state
state = newState
try
would definitely also not like to find ourselves in a realm where
anything but the validity of an argument would decide whose voice could
or could not be heard, or decicions/discussions would be influenced by
taking into account the emotions of the individuals involved.
Cheers,
mg
On 20/1
Hi Paul, no actual objections to the name - just a joke about the use of
offensive language, to lighten the mood on a heavy subject. With
honestly no intention to COCblock anyone ;-)
On 19/11/2020 03:57, Paul King wrote:
mg, what other suggestions do you have? Would you prefer "Comm
+1 for having one, -1 for calling it that
On 18/11/2020 08:52, Søren Berg Glasius wrote:
+1 for having a COC
Best regards / Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the
language, with a rating of 1.51%, with
Scala being a distant 3rd with 0.53% (pos 29), followed by Kotlin
with 0.38% (pos 36).
G-)
mg
PS: "SQL" is evidently on its way out, it continuously fell from nearly
4% around 2004 to 1.54% in 2020, barely keeping its place in front of
Groovy
;toString", we could also just make GV/NVS
use inspect, and only support GVD/NVSD besides that - then it would make
sense to use "inspect" instead of "toString" in NameAndValue#toString
also...
Cheers,
mg
On 07/08/2020 12:53, Paul King wrote:
I created a starting set o
read something about pattern
matching in Java, it looks to me like the current features set is quite
limited - but there are grand plans for the future...
Cheers,
mg
On 07/08/2020 20:46, Milles, Eric (TR Technology) wrote:
There is a pattern match syntax that is implemented using Groovy
macros
)
case Point3d(_, _, _):
return point3dCandidate
default:
throw TypeError("${NV(point3dCanditate) could not be
converted to Point3D")
}
}
Cheers,
mg
On 07/08/2020 12:53, Paul King wrote:
I created a starting set of NV, NVI and NVD macros similar (but
GitHub link ?-)
On 07/08/2020 12:53, Paul King wrote:
I created a starting set of NV, NVI and NVD macros similar (but
slightly different) to what mg has described previously. I see that as
a starting point for discussion.
manual/native-image/> ?
Thoughts ?
mg
easy part), as well as
last but not least c) to be sure that doing so will not just break part
or all of Groovy... ;-)
I think you grossly underestimate the amount of Groovy (internal)
knowledge you have :-)
Cheers,
mg
On 04/08/2020 18:27, Milles, Eric (TR Technology) wrote:
In terms of glob
from e.g. IntelliJ
Intellisense, and only show the stub implementation ? I use the NV
macros* extensively by now in my code, and what I found is, that always
having to select and import the stub class, and not the macro class is a
(small) hassle.
Cheers,
mg
*In practice it turns out the NV
et.accelerate()
Cheers,
mg
On 03/08/2020 07:57, Paul King wrote:
Hi everyone,
The GContracts project (design-by-contract extension for Groovy) has
been archived:
https://github.com/andresteingress/gcontracts/
I believe there is sufficient merit in the functionality it offers for
us to co
urn result" would therfore only leave the tapCls
}
We have discussed this before, but if it is doable, I still feel there
would be a lot of power in a feature like that... (not "inlining" for
performance - which often times will not be beneficial and just bloat
the compiled code - bu
In that case I would go back to Eric's suggestion, if we still feel we
need a macro solution... :-)
On 30/07/2020 01:10, Daniel Sun wrote:
Hi mg,
I like your idea, but it's hard for IDE to infer the type of `it` during
we coding.
```
returnIf(a > 6 && it > 10) { goo()
&& it>10) { return it }
How does the return know what to return in your example, btw... ?-)
3. Would the "it" variable in the ClosureList move from term to term,
i.e. it would always reference the last term before the current one, or
always refernce the first ?
Cheers,
mg
PS
quot; not considered an expression in Groovy, and should
we remedy that... G-)
4. Who is Johan ?-)
Cheers,
mg
On 30/07/2020 16:03, Daniil Ovchinnikov wrote:
I agree with Johan here, I’d even go ahead and write something like:
```
def chooseMethod(String methodName, Object[] arguments) {
:
returnIf(a > 6 && it > 10) { goo() }
Cheers,
mg
PS: If it = callB() were to be executed lazily, and no "it" argument
existed inside the condition, it would not be evaluated at all if
condition evaluates to false, making
returnIf() { goo() }
equivalent to
if() {
e
problematic area of whether/ how to support this syntax-wise.
If there is nothing blocking this, the question is if Groovy should
supply a basic version of such a macro (if Groovy is ever planning to
supply macros of its own) ?
Cheers,
mg
On 28/07/2020 16:08, Milles, Eric (TR Technology
Theodorou wrote:
On 27.07.20 18:13, MG wrote:
I am actually using this style quite often, because of a lack of good
alternatives. In the groovy code base you will find several places
looking like this:
foo = foo || m1()
foo = foo || m2()
foo = foo || m3()
foo = foo || m4()
or
foo = m1()
if (foo
Like - would still be nice if we had a more Groovy syntax for
Stream.of(...)/.stream() ... G-)
On 28/07/2020 12:30, Jochen Theodorou wrote:
well, with the streams API:
return Stream.of(null,Character.TYPE,Integer.TYPE).
map {doChooseMethod(methodName, adjustArguments(arguments, it)}.
dChosen = doChooseMethod(methodName,
adjustArguments(arguments, it))} if(methodChosen) {return methodChosen }else {throw new
GroovyRuntimeException("$methodNamenot found") }
}
(Disclaimer: Dry programmed code again, so can contain stupid mistake(s))
Cheers,
mg
On 27/07/2020 12:26, Jochen T
s.clone(), Integer.TYPE))
return methodChosen ??: throw new
GroovyRuntimeException("$methodName not found")
}
(if we had "??=" as "assign iff RHS != null", "??:" for "?: with
non-nullness", and could throw where an expression was expected)
Che
-single-return methods ;-)
Purely syntax wise I would prefer
return?
for the simple case,
and
return if
for the more complex one*.
I find
return(
confusing on what is actually returned.
Cheers,
mg
*Though I wonder if people would not then expect this if-postfix-syntax
to also work for e.g
@promote it more, that Groovy is a drop-in replacement? : Yes
On 26/06/2020 20:56, Jochen Theodorou wrote:
On 26.06.20 18:43, MG wrote:
[...]> Btw: I am wondering how many people are actually aware that copy
& paste
compatibility of Groovy with regards to Java is one of its
:18, MG wrote:
Hmmm - what about an @Java or @JavaCompatible annotation as the switch that
was already proposed.
That way Java to Groovy could just annotate all their ported classes (or at
least the ones that misbehave), and things would bve good.
The other way around would also work
Then you would force people to immediately convert a large number of
their Java source files to correct Groovy, which I think would put
people off.
What about introducing an explicit "property access" operator, as a
counterpart to the existing field access one ?
E.g.
this.x / super.x //
hink the annotation approach is mostly superior.
On 26/06/2020 18:48, OCsite wrote:
Another point against the file extension approach is the possibility to rewrite
only some methods into “proper” Groovy from the original Java code, leaving the
rest untouched.
All the best,
OC
On 26 Jun 2020, at 18:43
quot;just a script language" ?
And how can we promote that more ? G-)
Using a different file extension for "Java-comptible-Groovy", like
"*.jgroovy", would of course also work - but then we are back at "Groovy
does not really have a predetermined file extension for its so
...
(Alas it oftentimes seems, that as much as one would like to change
Groovy in some regard, and as much discussion is going on, the current
state is already pretty close to optimal, given Groovy's large scope of
requirements)
Cheers,
mg
On 26/06/2020 18:09, Jochen Theodorou wrote
into its 8th season), for which Wikipedia lists
entries in 34 languages:
https://en.wikipedia.org/wiki/The_Blacklist_(TV_series) :-)
Keep groovying,
mg
On 15/06/2020 03:05, Anne wrote:
Hi all
I support (eventually) removing the terms 'blacklist' and 'whitelist',
though my primary reason is diff
1 - 100 of 373 matches
Mail list logo
