Hi Saravanan,
could you just use union mounts / bind mounts under Linux, to combine
all the source directories as to appear as one ?
Cheers,
mg
Am 09.06.2025 um 20:26 schrieb Saravanan Palanichamy:
Thank you Eric
I dont know if I want incremental compilation. I'll state the pr
ovy).
1. (The only exception here is Groovy's "collectMany", which
should imho be "collectFlattened" o.s. (but also not
"collectFlat") ).
2. So I feel they should probably continue to be confined to the
"Java source
tures for strong yet flexible typing.
It also supports the creation of powerful scripts and elegant
Domain-Specific Languages.
It offers bidirectional interoperability with Java classes and
libraries, and supports language extensions through in-language macros,
AST transformations and meta-programming.
ages.
It has complete bidirectional interoperability with Java
classes/libraries, and supports language
extensions through in-language macros, AST transformations and
meta-programming.
/
Cheers,
mg
On 25/02/2025 04:21, Paul King wrote:
Hi folks,
Currently the intro description on groovy-lang.
prohibitive.
Cheers,
mg
On 06/02/2025 21:18, o...@ocs.cz wrote:
MG,
On 6. 2. 2025, at 21:05, MG wrote:
I was talking about an ideal world, as a starting point on how things
imho should behave (and why), as the point towards which one should
try to move as far as constraints such as
using immutable Groovy array lists instead, since it
was so much more convenient.
Cheers,
mg
extend the
collection/ or just return null."
Cheers,
mg
cally extending the size seems to be the worst option, given
that one too large index access could easily exhaust a computer's
main memory (-:
Cheers,
mg
On 06/02/2025 17:27, Milles, Eric (TR Technology) via dev wrote:
Is there any explicit statement about how indexing beyond th
+1
On 21/01/2025 21:44, Paul King wrote:
Hi folks,
The Grails project is keen to join the ASF. The suggested path into
the ASF is for Groovy to act as the incubating project. This means
that we'll have a little work to do to help them become familiar with
the ASF and get them up to speed. The i
As I have said before, after Groovy has made the step to join the Apache
family a while ago, it seems like a good and logical step for one of its
biggest sister projects to do the same G-)
Cheers,
mg
On 16/01/2025 17:31, Paul King wrote:
Hi folks,
The Grails project is keen to join the ASF
t working with Groovy generated bytecode)
Cheers,
mg
On 20/12/2024 17:52, Jochen Theodorou wrote:
On 20.12.24 14:24, Paul King wrote:
Well, that would be the idea. Maybe not recommended, but currently you
can still use the 4.0.x groovy-servlet jar with Groovy 5. At least for
Groovy servlets with
+1 G-) mg
On 11/12/2024 02:32, Paul King wrote:
I created this pull request which clarifies things somewhat:
https://github.com/apache/groovy/pull/2133
But feel free to create an alternative if you think it can be improved further.
Cheers, Paul.
On Wed, Dec 11, 2024 at 12:58 AM Milles, Eric
is of course not trivial, but
more importantly some people here have in the past expressed
concerns that it is actually a dangerous thing to support, that
people could over- or abuse.
4. And from my memory these are the reasons this never moved forward...
Cheers,
ince
iterable.each has been around forever, it's only competition at the
time being using the foos iterator explicitly in a C-like while loop ;-)
4. But that is not what you wanted to talk about - so on to email #2...
Cheers,
mg
On 04/12/2024 18:03, OCsite wrote:
MG,
On 4. 12. 2024
resorting to a
if(foo instanceof FooChild) { ... } cascades G-)
Cheers,
mg
On 04/12/2024 11:02, Gianluca Sartori wrote:
> What you call "Java Compatibility" many Groovy users would call
expected features.
> My suspicion is that for each feature you might want to move
e in the near
future... ;-)
Cheers, mg
PS: I googled a bit, and I could not find in general that ppl think var
in Java is something you should avoid. Instead, as with any language
feature, one can over-/abuse it, thereby making code less readable than
when using explicit types.
It is funny thinking abou
ode.
2. Do you maybe have a link to the "using 'var' in Groovy code" talk
you mention ?
Cheers,
mg
On 26/11/2024 10:10, Gianluca Sartori wrote:
I have the feeling that your confusion comes from the fact that
you think Groovy = Python in the Java world, and Python
://docs.oracle.com/en/java/javase/17/language/local-variable-type-inference.html
https://docs.oracle.com/javase/specs/jls/se10/html/jls-18.html
With var correctly inferring types from its RHS assignment, this can
finally also be added to final ||-)
Cheers,
mg
PS: I googled a bit, and I could not find in
large sea here.
In general, please reread all my previous replies, I am pretty sure I
have already answered all other questions/points you keep bringing up,
in some cases with sample code... :-)
Cheers,
mg
Java syntax compatible.
2. var implies something different, more restricted than def (see
replies by other mailing list members).
3. Doing so would prevent a possible future extension of Groovy to do
type inference where var is used.
Cheers,
mg
Hi OC,
I had to check (since I don't use code like that), and it is not
overriding/overloading the new operator per se, but replacing a ctor of
a class through its metaClass (see code below).
Cheers,
mg
import groovy.transform.Canonical
@Canonical class Goo { String s }
@Canonical
ence
using var x here just always uses type Object
2. x = "abc" // ok, an Object variable can hold any type
Cheers,
mg
On 22/11/2024 09:58, Gianluca Sartori wrote:
var was always intended for the case of "type inference from an
assignment", the way
use
var, which at this point only exists to satsify Groovy's goal of maximum
Java syntax compatibility where possible, and in a possible future
extension could support type inference, which is probably not what you
want/expect when using var as a synonym for def :-)
Cheers,
mg
On
Groovy, man... G-)
Cheers,
mg
On 12/11/2024 12:36, Paul King wrote:
Hi folks,
We'd like to welcome Søren Glasius to the Groovy PMC. Søren has been a
committer since 2020. As well as being a long-time Groovy supporter
many of you will know him from his work on Grails and his wonderful
+1
On 23/10/2024 00:10, Paul King wrote:
Hi folks,
The Geb project[1][2] has been a pre-eminent web testing/browser
automation solution in the Groovy ecosystem for some time. Recently it
has become mostly a one-person project with the main maintainer now
being drawn in other directions. It has
Hi Jonny,
welcome, that is good to hear, and from what Paul says, path 3 indeed
looks to be the most sensible route :-)
Cheers,
mg
On 16/10/2024 21:54, Jonathan Carter wrote:
Thanks, Paul.
Just to introduce myself to the folks on the list, Jonny Carter here!
I'm taking over as one o
o your 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 ?
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
the effort, 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.
at.
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 I
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
icing 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:
u use 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
eory you might find 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... :-)
Che
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 that no
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
continuously
rsync-upload these files to the server after small code changes becomes
a factor in turnaround time...
Cheers,
mg
(Or we could 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 Ki
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
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 eleme
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 the
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 beats
o
prevent any conventional 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
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 they
LAST_NAME = new Column(this, 'LAST_NAME ', 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 cr
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
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:
On
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 can adj
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 saf
eneral, not in all possible
applications. 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
ich 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 &q
efore, 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 ar
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
T 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.
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
12, 31, 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
o 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/
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
etAt; the 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
://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 more on bu
t 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
on, even
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
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
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. "W
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
fulNullPointerExceptionTest$C.getB()" 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
otation 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), G
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 if
3.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
'sem
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 wro
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
If Gradle requires compatibility with the old parser, it seems to me
this is the way to go, unless someone has a very convincing example
showing the new way would actually be better...
Cheers,
mg
On 11/02/2021 11:17, Paul King wrote:
Thanks for the feedback. I have also seen the convention
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
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 code. W
closure 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 :-)
Che
oth 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
inherently 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.
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/11/2
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 change
1 - 100 of 429 matches
Mail list logo
