Thanks, Paul!
mg
On 22.07.2017 02:35, Paul King wrote:
Nice!
pe.retrieveTreeNodeRow(orgUnit:123,
orgItem:456) .
mg
*Here a parameter object might be the better choice. But typically the
number of paramters was small at the beginning, and grew over time, so
initially no need for a paramater object existed. Again the refactoring
time needed to introduce a p
functionality interface between the given classes
here...
I would also have thought of the exact same syntax - can you explain why
you think it would break future extensions, Paul ?
mg
On 23.07.2017 01:50, Paul King wrote:
I would be leaning towards -1 without further justification. Even
How about the same support as languages like Ruby and Smalltalk provide ?
On Sat, Jul 22, 2017 at 5:17 PM MG <mailto:mg...@arscreat.com>> wrote:
Hi,
having recently explained why Groovy is my language of choice got me
thinking about the few areas of Groovy where I perso
ddition my son has also started to mod
Minecraft a bit, and I wanted to use this to introduce him to Groovy
- after he has suffered through a bit of Java ;-) ).
mg
that might not be apparent at first - plus a
Jira issue is a good place for us to suggest hints on how to get started.
Some more comments inline below ...
Cheers, Paul.
On Mon, Aug 21, 2017 at 6:25 AM, MG <mailto:mg...@arscreat.com>> wrote:
Hi,
before I create change r
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Support making all method/ctor parameters final by default through
"autofinal" Groovy compiler flag:
1. Foo(int x, String s) { // final keyword is auto added to all
parameters, if compiler flag is set, i.e. this automatically
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Deduce the type of final fields from their assigned value:
class Foo {
final device = new PrinterDevice(...) // device field will have
type PrinterDevice instead of Object when reflection is used on
class Foo
}
Rationale: Wh
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Introduce a "var" (o.s.) keyword that allows deduction of type
through assignment:
var device = new PrinterDevice(...) // device variable will have
type PrinterDevice without the need to explictely state that
Rationale: This is
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Always allow ctor calls without new keyword:
final foo = Foo("abc") // creates a new Foo instance by calling
Foo class ctor with signature
Rationale: new keyword was necessary in C++ to distinguish heap vs
stack variable allocati
27;d mention list and map constructors [1], with those you
can not only leave out the `new` keyword but also leave off the type
(at least on the RHS)
Foo foo = ['abc']
[1] http://groovy-lang.org/semantics.html#_list_and_map_constructors
On Tue, Aug 22, 2017 at 4:16 PM, MG <mailto:mg.
instanceof Integer
assert result == 42
Cheers, Paul.
On Wed, Aug 23, 2017 at 8:45 AM, MG <mailto:mg...@arscreat.com>> wrote:
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Deduce the type of final fields from their assigned value:
class Foo {
final dev
o:pa...@asert.com.au>> wrote:
On Wed, Aug 23, 2017 at 8:32 AM, MG mailto:mg...@arscreat.com>> wrote:
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Support making all method/ctor parameters final by default
through "autofinal" Groovy
Hi Jochen,
On 25.08.2017 10:01, Jochen Theodorou wrote:
On 23.08.2017 00:32, MG wrote:
[...]
Apart from making the code easier to
read & safer, it also allows compiler optimizations (and in the absence
of a true const-keyword, at least for fundamental data types it has the
same ef
Hi Jochen,
On 25.08.2017 10:05, Jochen Theodorou wrote:
On 23.08.2017 00:52, MG wrote:
Hi Paul,
On 21.08.2017 04:30, Paul King wrote:
Introduce a "var" (o.s.) keyword that allows deduction of type
through assignment:
var device = new PrinterDevice(...) // device var
On 25.08.2017 10:09, Jochen Theodorou wrote:
for me that is a feature likely to go. If you define a dynamic ctor,
it should return an object of at least the type that the ctor is for.
I do not care about subclasses or such, but I don't like Date result =
new Date() to fail.
I did not expect
Hi Paul,
On 25.08.2017 04:15, Paul King wrote:
On Fri, Aug 25, 2017 at 11:03 AM, MG <mailto:mg...@arscreat.com>> wrote:
I was just referring to your "You can already leave off the
"clutter" and apply a CodeNarc rule[1] to detect "bad" style&qu
On 27.08.2017 10:19, Paul King wrote:
On Sun, Aug 27, 2017 at 12:57 PM, MG <mailto:mg...@arscreat.com>> wrote:
On 25.08.2017 04:15, Paul King wrote:
Actually, I think an @AutoFinal transform might be a good
addition. I'm happy to work on that with you if you li
Congratulations :-)
I also think it is great that someone is moving an existing Groovy
library into a more typesafe/static realm - I believe this is essential
for the continued success of Groovy...
On 22.09.2017 18:13, David Clark wrote:
All,
The HttpBuilder-NG team is excited to announce th
Not bad indeed... :-)
Ursprüngliche Nachricht Von: Guillaume Laforge
Datum: 26.09.17 16:25 (GMT+01:00) An:
users@groovy.apache.org Betreff: A few stats about Apache Groovy
Hi all,
The RebelLabs '17 report ranks Apache Groovy 3rd in language popularity, right
behind Java 7 an
ery bad choice
imho, since at least to me it implies a value type, or something which
is const(ant)), for the case that the assignment is final...
So what are the plans for "var" (and the related type inference when
using "final") in Groovy right now: Wait until the Java
ps to catch null-pointers as early as possible
for debugging purposes, it still crashes your application - so avoiding
this problem wherever possible is imho the way to go here...
Btw, what do you have to do to become a first class first-class Android
language, and why isn't Groovy in
t case one can just define a
local, non-final variable and assign the parameter to it).
Cheers,
mg
ove it
from the class level to just the violating methods/constructors and
then eventually remove all once you have completed the conversion
process. We have the same kind of approach in place for CompileStatic.
Cheers, Paul.
On Mon, Oct 9, 2017 at 5:58 AM, MG <mailto:mg...@arscreat.com>>
added the ability to disable. It is similar to what we do in other
places and just because the flag is there, doesn't mean you have to
use it. Anyway, have a play and let me know what you think.
Cheers, Paul.
On Mon, Oct 9, 2017 at 10:42 AM, MG <mailto:mg...@arscreat.com>> wrote:
blackdrag suggested to move this
https://issues.apache.org/jira/browse/GROOVY-8329
discussion from Jira to this list, so I am replying here:
I agree with Endre Stølsvik: I think Groovy should strengthen its
language support for statically compiled use, and I agree it should move
towards making
PS: Just reread my post from yesterday, and wanted to add that I am of
course happy that, like I said earlier, according to one study/metric it
looks like Groovy is currently the #2 JVM language (with 3%) :-)
However, since it is "like Java, just better", I am convinced it could
be much higher (
uses the NullObject.iterator(), i.e. does not throw but instead iterates
over an empty collection by design ?
Cheers,
mg
the name is prefixed with the canonical trait class name, so it cannot be
matched directly, so I would need to subtract the trait prefix... yuk
So before I go down this inelegant route (which might break in the future), I
wanted to ask if anyone has a better suggestion ?
Thanks,mg
azz -> GroovyReflectionClass./createFromClass/(clazz)
}
}
Cheers,
mg
"If we want to keep static Groovy near Java as much as possible..." - who wants
that ? ;-)
That is pretty much what I expected. So warning developers about this is the
best thing to do.
Btw, do we already have an official "@CompileStatic gotchas" section s
On 15.12.2017 20:29, Jochen Theodorou wrote:
On 15.12.2017 16:44, mg wrote:
"If we want to keep static Groovy near Java as much as possible..." -
who wants that ? ;-)
Was just kidding, of course, as you know for Minecraft modding I very
much want that.
Btw, do we alrea
Good move, Russell :-)
Ursprüngliche Nachricht Von: Russel Winder
Datum: 21.12.17 17:59 (GMT+01:00) An:
d...@groovy.apache.org Cc: GPars Users ,
Groovy_Users Betreff: Re: GPars progress [was CC and
build revision]
I have started a TODO wiki page at https://github.com/GPars
Hi all,
I have created a jira for my proposed toDebugString Groovy feature:
https://issues.apache.org/jira/browse/GROOVY-8431
Cheers,
mg
core concept
Out of curiosity, you know about the dump() method on Object?How close /
different is it from your proposal of toDebugString()?(dump() had that same
purpose initially)
Guillaume
On Wed, Jan 3, 2018 at 6:39 PM, MG wrote:
Hi all,
I have created a jira for my proposed toDebugS
(requires IDE support), generate the Groovy sources
in textual form, ... ?
Cheers,
mg
On 07.01.2018 17:14, Daniel Sun wrote:
Hi Russel,
`[1, 2, 3, 4, 5].parallel.reduce{a, b -> Math.min(a, b)}` is much
groovier than ` [1, 2, 3, 4, 5].parallelStream().reduce{a, b -> Math.mi
to implement), to get Groovy up to speed in this regard.
Cheers,
mg
On 12.01.2018 01:57, Paul King wrote:
Hi all,
Would there be interest in a @UtilityClass annotation - similar to
lombok's:
https://projectlombok.org/features/experimental/UtilityClass
It is similar to @Category in
I think the name is good.
I feel @Static would be a natural choice to be extended to support
typical METHODS or FIELDS paramters, to only make these static, which
does not make sense for an utility class, which by definition is
static-only.
On 12.01.2018 02:44, David Clark wrote:
I vote ye
I have created a Jira issue about Groovy non-map based named parameter
support:
https://issues.apache.org/jira/browse/GROOVY-8451
On 16.01.2018 06:54, Paul King wrote:
We have a number of open issues around improving named-argument support.
I am currently doing a spike around one AST transform
it to a specific year:
That way people who no longer are Groovy contributors do not carry the
title forever (the Russian guy who is now working on Kotlin comes to
mind), and on the other hand some people could get the title several
years in a row, as a sign of continued gratitude.
Cheers,
mg
On 13.0
r
Gradle/Kotlin for that matter), but to me it looks like giving someone
honors who is working on what looks like Groovy's biggest rival at the
moment might, might not be the smartest move...
A long reply for sure, but it's a complicated topic,
mg
On 14.02.2018 12:23, Cédric Cham
ow, as a sign of continued gratitude.
If they do, they would be good candidates for the PMC.
Cheers,
mg
On 13.02.2018 14:13, Søren Berg Glasius wrote:
+1 on the name!
I think it's cool to differentiate the Groovy award from other
awards like Java Rock-stars and Java
, and on the other hand some people could get the title several
years in a row, as a sign of continued gratitude.
If they do, they would be good candidates for the PMC.
Cheers,
mg
On 13.02.2018 14:13, Søren Berg Glasius wrote:
+1 on the name!
I think it's cool
payment as such, but could
also be a thank you that would e.g. allow a major contributor to take
his significant other out for a nice dinner.
Is this frowned upon (or even forbidden) by the Apache foundation ? Does
someone of the main devs not like the idea ?
mg
One other thing from the no-brainers section that Kotlin does better
than Groovy: Ctors can be called without the new keyword.
(Groovy's offer in this regard is alas severly lacking, hence nobody
uses it...)
On 14.02.2018 22:50, MG wrote:
PPS: I do not agree with you assessment of K
with Java,
fixing bugs etc.
Cheers,
mg
On 16.02.2018 11:49, Jochen Theodorou wrote:
Am 16.02.2018 um 03:27 schrieb Paul King:
Actually, Apache also accept donations but I think the standard
policy is that it isn't then directed back to a specific project.
I actually am of the impressi
That should be no problem, I would be happy to do a Groovy "thank you"
mug o.s. :-)
On 16.02.2018 17:11, Mario Garcia wrote:
+1 but also keep in mind that sometimes could be also something as
simple as a "grateful box pack" with a T-shirt, sticker or a mug. I
would love that too.
Mario
El
rries a lot of implementation effort, and also does not come
free side effect wise). So the implementation side can easily be no
no-brainer - but that does imho not make Kotlin a language with a
language design that Groovy can learn from...
Cheers,
mg
ved using a simple text macro.
So its not really a closure, it is "just a (regular) block construct
which gets a head supplied by the code from a user method".
Cheers,
mg
ons in the dynamic case,
even if Groovy ignores the setting.
And as always the argument remains that declaring things which are final
as final is good for other people reading your code :-)
Cheers,
mg
able to lend any support...
For me that would probably be the #1 feature I would fund :-)
Cheers,
mg
(and consecutively Groovy) is an artifact
coming from C++, where stack based alloaction uses the ctor call alone,
and the new keyword before the ctor call result in heap allocation -
which is of course the only allocation variety supported in Java/Groovy,
so no need to discern between the two cas
On 18.02.2018 13:38, Eric Kinsella wrote:
+1up on Groovy Stars.
"Get a life" ;-)
But seriously, all the people one-upping "Groovy Stars" - consider
whether that name really sends the right professional message with
regards to Groovy ? I am convinced it does not.
Managers who might decide w
their FAQ, but here one could probably assume that many potential Groovy
backers would already have an account...).
Do they support specific funding foals also (which typically attract
more funding), or is a subscription only model ?
Cheers,
mg
On 18.02.2018 14:15, Eric Kinsella wrote:
I
lot of money and are known and are revered by millions of people.
Calling yourself a "star" if you are not even close to that level
feels tacky to me.
Cheers,
mg
On 19.02.2018 12:03, Søren Berg Glasius wrote:
I disagree with MG.
A star is an object that shines, and in this
Following the sports analogy, what about
"Groovy MVPs"
?
Any game can have Most Valuable Players (even if only one is typically
crowned in the US), and I think "Groovy announced its 2018 MVPs" has a
nice ring to it.
Cheers,
mg
On 19.02.2018 12:03, Søren Berg Glasiu
onym, btw, according to
https://acronyms.thefreedictionary.com/STAR
On 19.02.2018 20:39, Guillaume Laforge wrote:
For me, MVP sounds too much like Minimum Viable Product :
https://en.wikipedia.org/wiki/Minimum_viable_product
On Mon, Feb 19, 2018 at 8:32 PM, MG <mailto:mg...@arscreat.com>> wrote:
F
GrooVIP I like, it's in the tradition of GString... :-)
"The Apache Groovy project announced its 2018 GrooVIPs" works for me.
mg
Ursprüngliche Nachricht Von: Guillaume Laforge
Datum: 20.02.18 11:07 (GMT+01:00) An:
users@groovy.apache.org Betreff: Re: G
eptional Community Member
(Groovy ECM) or Groovy Distinguished Community Member (Groovy DCM). New
acronym, professional enough, focusing
on the overall community and not only the language per se.
Kostas
On 19/2/2018 10:26 μμ, MG wrote:
I have never heard "MVP" = "Minimu
r
(Groovy ECM) or Groovy Distinguished Community Member (Groovy DCM). New
acronym, professional enough, focusing
on the overall community and not only the language per se.
Kostas
On 19/2/2018 10:26 μμ, MG wrote:
I have never heard "MVP" = "Minimum Viable Product"
Groovy Bright Giants(a subclass of Red Giants ;-) )
Ursprüngliche Nachricht Von: mg Datum:
20.02.18 20:29 (GMT+01:00) An: users@groovy.apache.org Betreff: Re: Groovy
Champions proposal feedback - Groovy MVPs ?
Groovy (Red) Giants
Ursprüngliche Nachricht Von
would
probably have a larger number of people giving smaller amounts to fund
a development goal together...
Cheers,
mg
On 21.02.2018 15:50, Mario Garcia wrote:
Ithought this could be worth sharing.
The company I work for developed some time ago, Tribe
(https://tribe.taiga.io/)
Tribe is a
would evidently imho be such a message. )
Cheers,
mg
On 16.02.2018 01:24, Jochen Theodorou wrote:
On 14.02.2018 22:38, MG wrote:
[...]
Would you suggest we also honor Groovy inventor James Strachan, who
wrote in 2009 in his Blog "I can honestly say if someone had shown me
the Programming
general IT topic are given. I have added some Groovy related info
to WIkipedia on multiple occasions, seeing that Scala, and later a
surprising amount of Kotlin (for such a young language) were already
there...
Cheers,
mg
On 25.02.2018 10:53, Guillaume Laforge wrote:
James Stachan's qu
/jira/browse/GROOVY-8490
Please comment,
Cheers,
mg
://issues.apache.org/jira/browse/GROOVY-8491
Cheers,
mg
dynamically allocated/deallocated from the os), continuous concurrent garbage
collection without freeze-the-world fallback, and application startup (warmup)
time improvements.But I am worried about Groovy compatibility (they only
mention Scala explicitly on the web page)...
Cheers,mg
Thank you to all that gave feedback :-)
Russel, could you elaborate a bit on the incompatibilities you mention ?
On 08.03.2018 15:45, Russel Winder wrote:
On Thu, 2018-03-08 at 13:09 +0100, mg wrote:
Hi,
I would be interested to hear if anyone has experience with using
alternative JVMs with
On 08.03.2018 15:05, Eric Helgeson wrote:
PS: Maybe worth reaching out to Azul and asking what tests they did to
mention Scala - and to add Groovy there too :D
I don't know why Groovy is so often flying under the radar - maybe to do
with the fact that it is still not seen as a "full blown lang
patible" topic at the top of
the funding table in https://issues.apache.org/jira/browse/GROOVY-8503.
Cheers,
mg
*I think we should see if this appoach does not suffice, before going
down the route of a
Kickstarter/Indiegogo/tribe.taiga.io/bountysource.com/Patroon/fundrequest.io
- tha
ld (similar to
my @Memoized method).
3. In general: What is the exact order that fields get initialized in
Groovy - and is this behavior expected to change in the future ?
Cheers,
mg
such a
general problem, that I would have thought people would already have
complained about this in troves...
Cheers,
mg
On 10.03.2018 22:10, Paul King wrote:
There is a known bug in trait initialization for final fields:
https://issues.apache.org/jira/browse/GROOVY-8281
It's on my list
d the funding Paypal link should
go on the main Groovy web page. The important thing here would be to get
people to commit to regular funding...
Cheers,
mg
On 11.03.2018 14:58, Daniel.Sun wrote:
Hi MG,
After Pivotal stopped sponsoring Groovy, Groovy evolves much slower
than before. As w
iple people would already possible through the Jira
approach (just pledge in the comment section).
Splitting money between multiple contributors is a problem that we can
hopefully solve once there is some money to split.
Cheers,
mg
On 11.03.2018 17:28, Daniel.Sun wrote:
BTW, each issue or fe
Sure :-)
Ursprüngliche Nachricht Von: "Daniel.Sun"
Datum: 11.03.18 17:52 (GMT+01:00) An: us...@groovy.incubator.apache.org
Betreff: Re: Fund Groovy Development - Jira Task
Well, my bad... I just wish more and more volunteers would involve in the
development of Groovy :)
Chee
Sure :-)
Ursprüngliche Nachricht Von: "Daniel.Sun"
Datum: 11.03.18 17:52 (GMT+01:00) An: us...@groovy.incubator.apache.org
Betreff: Re: Fund Groovy Development - Jira Task
Well, my bad... I just wish more and more volunteers would involve in the
development of Groovy :)
Chee
you have to call matches() on the matcher...
Ursprüngliche Nachricht Von: Vladimir Frelikh
Datum: 14.03.18 12:17 (GMT+01:00) An:
users@groovy.apache.org Betreff: groovy regex match group
Hello,could someone help with the following code:
text = 'test'def matcher = text =~ /(te
ps: if(matcher) invokes Groovy truth (asBoolean()), which calls find() on the
matcher
Ursprüngliche Nachricht Von: Vladimir Frelikh
Datum: 14.03.18 12:17 (GMT+01:00) An:
users@groovy.apache.org Betreff: groovy regex match group
Hello,could someone help with the following cod
" and emotional involvement of a
Kickstarter to give sizable sums...Feel free to prove me wrong everyone :-) )
(Also I cannot set this up, since you already need to know where the money
goes, etc...)
Cheers,mg
Ursprüngliche Nachricht Von: Jochen Theodorou
Datum: 15.03
Vote to get Groovy 3.0 support in IntelliJ as early as possible:
1. https://youtrack.jetbrains.com/issue/IDEA-188050
2. Log in
3. Click on icon right of "Voters" on the right
13 votes and counting,
Cheers,
mg
40 votes to date - great job everyone... :-)
Cheers,
mg
On 16.03.2018 09:18, Edd Grant wrote:
Also done!
Cheers,
Edd
On 16 March 2018 at 03:31, Daniel Sun <mailto:realblue...@hotmail.com>> wrote:
Done :-)
Cheers,
Daniel.Sun
--
Sent from:
http://groovy.
eharutyun...@fipsoft.com>>:
done
On 03/16/2018 09:20 PM, MG wrote:
40 votes to date - great job everyone... :-)
Cheers,
mg
On 16.03.2018 09:18, Edd Grant wrote:
Also done!
Cheers,
Edd
On 16 March 2018 at 03:31, Daniel Sun mailto:realblue...@hotm
s, but where one would need to
pass a large number of parameters to a helper method that coud be
introduced, or one would really have to try hard to come up with a
meaningful method name (implying that the functionality is too
small/specialized to be moved into a seperate method).
Thoughts ?
mg
t this creates a Closure instance, so it is inefficient. If Groovy had
"inline closure" support, I would use that, but since it looks like this
is still a long way off (if it ever comes - it was shot down a few years
back when someone else created a ticket for it), I suggest this special
version of it.
Cheers,
mg
I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be
switchable in IntelliJ, anything else would make little sense to me.But we have
the expert on this mailing list, who should be able to tell us... :-)mg
Ursprüngliche Nachricht Von: "Daniel.Sun&quo
I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be
switchable in IntelliJ, anything else would make little sense to me.But we have
the expert on this mailing list, who should be able to tell us... :-)mg
Ursprüngliche Nachricht Von: "Daniel.Sun&quo
we have own
parsers for (almost) each language.
—
Daniil Ovchinnikov
Software Developer
JetBrains
jetbrains.com
“Drive to develop”
> On 21 Mar 2018, at 22:30, mg wrote:
>
> I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be
> switchable in IntelliJ, anythin
That answers the 2.6 question, thank you Daniil :-)mg
Ursprüngliche Nachricht Von: Daniil Ovchinnikov
Datum: 22.03.18 13:59 (GMT+01:00) An:
users@groovy.apache.org Betreff: Re: Groovy 3 lambda, method reference, default
methods
It will be deduced it from library with a
ouch Bar (Magic
Toolbar)" has 789 votes, just slightly below the front runner, "CPP-494
Support Makefile projects" at 816 - maybe someone could tell these guys
it's 2000++++ ;-) )
mg
On 21.03.2018 14:36, Daniel.Sun wrote:
Here is the li
uot;Groovyc: [Static type
checking] - Cannot find matching method
groovy.GroovyGeneralSpike$Foo#sonOfFooMethod()." if(finstanceof SonOfFoo) {
println f.sonOfFooMethod()// works because of flow typing }
}
Cheers,
mg
On 23.03.2018 15:42, Paul King wrote:
The Parrot parser already ha
pe:
static class Main {}
@Test @Ignore @CompileStatic void main() {
// mg: was "var x = new Object() {" Object x =new Object() {
public void myMethod() { System.out.println(new Date()); }
};
x.myMethod();// okay because the inferred type is the AIC // mg: Was "var y =
e, I would hate to conceptually loose flow typing (which is a
really powerful feature) just because of using var :-)
Cheers,
mg
On 25.03.2018 15:19, Paul King wrote:
For the majority of cases, you will be able to conceptually think of
it as if the declaration type of the LHS is the inferred t
Hi guys,
for everyone that has not seen it yet, there is a big article on the
upcoming Groovy 3.0 in the newest Java Magazine:
http://www.javamagazine.mozaicreader.com/MarApr2018/Default/61/0#&pageSet=61&page=0&contentItem=0
Cheers,
mg
Quick question, since I just came across that again in Groovy 2.4: Will
Groovy 3.0 support passing multiline lists/maps to a method without
surrounding it with brackets ?
E.g.
def foo(List l) { ... }
could be called giving
final result = foo [
"some rather long literal string argument",
y would conceivably not be used if someone was going for an index
expression.
Backward compatibility breaking changes aside, would the Parrot be able
to discern these cases ?
Cheers,
mg
On 06.04.2018 18:25, Daniel.Sun wrote:
Hi mg,
`foo []` is ambiguous, parser can parse it as index
ay afaiks (Java 9 modules), so you do it here, or
not for a long time...
Would be interested what others think, or if someone has a counter
example that makes it clear it is a bad idea to go down that route,
mg
On 06.04.2018 19:49, Daniel.Sun wrote:
Hi mg,
It's dangerous to l
ard to
the classic error of not updating what you print in relation to what you
return from the method.
I would also require one or more space or tab characters after the
"list" in your multiline example, i.e.
// Compiles to list([0])
list [
0
]
instead of
// Does not co
Are you using the Gradle build cache ?Have you tried building the code using
the IntelliJ build system (I am not sure if you mean that by "In IntelliJ this
is not flagged up as an issue either" or that only Intellisense does not
complain) ?
Cheers,mg
Ursprüngliche Nachricht -
appears through just restarting the build multiple times.
Rebuilding the same module multiple times in a row seems to have a much
higher chance of the build failing again (starting a minimal rebuild of
the whole project takes forever and is practically guaranteed to fail).
Cheers,
mg
e breaking edge cases, because I feel
they are quite rare in practice, the compiler catches them, and they are
easy to fix.
Cheers,
mg
On 29.04.2018 15:29, Paul King wrote:
+1
For completeness, I added some more details about the breaking changes
and workarounds into the issue - included be
1 - 100 of 234 matches
Mail list logo
