On 23.06.2016 08:00, Thibault Kruse wrote:
On Tue, Jun 21, 2016 at 6:44 PM, Cédric Champeau
wrote:
A strong -1 for both options. We already have 2 variants of Groovy today,
indy and non indy, and in practice *nobody uses the invokedynamic version*
because it's impractical to use. ...
Adding a
On Tue, Jun 21, 2016 at 6:44 PM, Cédric Champeau
wrote:
> A strong -1 for both options. We already have 2 variants of Groovy today,
> indy and non indy, and in practice *nobody uses the invokedynamic version*
> because it's impractical to use. ...
> Adding a new dimension, which is orthogonal to i
Perhaps a custom type checker extension could be fed with the jdbc
metadata...
Le 22 juin 2016 7:41 PM, "Shil Sinha" a écrit :
> Hi Marc,
>
> You could use the map access syntax i.e. foo['id'] instead and cast/coerce
> the result to the appropriate type.
>
> On Wed, Jun 22, 2016 at 1:37 PM Wilson
On 22.06.2016 18:55, Mr Andersson wrote:
[...]
We, at our company can only ship groovy if it is fully static, no way to
manipulate. It's difficult to hammer it through otherwise. Big
enterprise JEE companies don't take risks, especially when the tools are
handed over to 5 000 dev across the globe
Hi Marc,
You could use the map access syntax i.e. foo['id'] instead and cast/coerce
the result to the appropriate type.
On Wed, Jun 22, 2016 at 1:37 PM Wilson MacGyver wrote:
> Hi,
>
> If I want to use compileStatic with groovy.sql, how would I do that?
>
>
> the problem as far as I can tell is
Hi,
If I want to use compileStatic with groovy.sql, how would I do that?
the problem as far as I can tell is
sql.eachRow("select id, from whatever") { foo ->
...
foo.id
}
returns data that is known at runtime
but at compile time. there is no way to know that the SQL statement returns
a
On 06/21/2016 11:34 PM, Winnebeck, Jason wrote:
I can say as someone who writes Groovy on a daily basis for about a
year now on a project that uses CompileStatic by default on a team of
6-10 that we haven’t had many problems forgetting @CompileStatic or
been too annoyed with it. Although as
On 22.06.2016 14:26, Mr Andersson wrote:
[...]
I am not saying that, only that my uncompiled code has to be static. As
if it has the annotation on.
well, then you actually want @TypeChecked I guess
A global flag might be problematic for relying on external libraries,
but if they are already c
On 22.06.2016 13:41, Russel Winder wrote:
In case no-one has mentioned this…
On Tue, 2016-06-21 at 14:24 +0200, Mr Andersson wrote:
[…]
I've heard about Groovy++ but I believe that's dead by now, no?
[…]
Yes Groovy++ is gone. Static compilation of normal Groovy code is what
to do.
and
On 06/22/2016 07:02 PM, Mr Andersson wrote:
On 06/22/2016 03:06 PM, Alessio Stalla wrote:
Also good tests help. However I agree that if you prefer the
tradeoffs that static languages give you then probably Groovy is not
the wisest choice.
It's nice to have good speed in critical sections
On 06/22/2016 03:06 PM, Alessio Stalla wrote:
Also good tests help. However I agree that if you prefer the tradeoffs
that static languages give you then probably Groovy is not the wisest
choice.
It's nice to have good speed in critical sections of the code without
having to rewrite them in
On 06/22/2016 02:35 PM, Winnebeck, Jason wrote:
I'd say the dynamic features of Groovy are the strongest case for Groovy right now, and a
fully static Groovy would be a mistake because there are already other solutions out
there for that. I'm not sure of any other language out there that can
In Portofino applications we allow to hot reload Groovy code using
GroovyScriptEngine. It is great for development and handy for fixing quick
issues in production too, but if it's mission critical I wouldn't rely on
it yet. Even if it has improved much over time (thanks to Jochen's work!)
sometimes
Also good tests help. However I agree that if you prefer the tradeoffs that
static languages give you then probably Groovy is not the wisest choice.
It's nice to have good speed in critical sections of the code without
having to rewrite them in Java, but a fully static Groovy IMHO is just a
quirkie
> People want to be able to refactor without risking of the code eventually
> breaking totally, and that's the problem with Groovy. Code will eventually
> become stale and stop working if it is put on layway for a while. No compile
> time checks is a problem for anyone interested in code quality.
I'd say the dynamic features of Groovy are the strongest case for Groovy right
now, and a fully static Groovy would be a mistake because there are already
other solutions out there for that. I'm not sure of any other language out
there that can do what can be done with missingMethod and Closure
On 06/22/2016 09:59 AM, Thibault Kruse wrote:
I don't think the dynamic nature of Groovy is in general regarded as
the weakest point of Groovy right now.
I do think that's the biggest problem. Groovy was the second largest JVM
language in 2010, but it is not really that big anymore, mostly o
On 06/22/2016 01:12 PM, Jochen Theodorou wrote:
On 22.06.2016 09:59, Thibault Kruse wrote:
I don't think the dynamic nature of Groovy is in general regarded as
the weakest point of Groovy right now. However, I believe a fully
static Groovy may still be preferrable than the dynamic Groovy, mo
In case no-one has mentioned this…
On Tue, 2016-06-21 at 14:24 +0200, Mr Andersson wrote:
>
[…]
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> […]
Yes Groovy++ is gone. Static compilation of normal Groovy code is what
to do.
--
Russel.
=
On Wed, Jun 22, 2016 at 1:12 PM, Jochen Theodorou wrote:
>
> Yes, there are bugs, but the static side has surely more generics bugs, than
> the dynamic side. Implementation wise you move from the runtime to the
> compiler, but the complexity is imho higher in the compiler, because the
> abstractio
On 22.06.2016 09:59, Thibault Kruse wrote:
I don't think the dynamic nature of Groovy is in general regarded as
the weakest point of Groovy right now. However, I believe a fully
static Groovy may still be preferrable than the dynamic Groovy, mostly
from the point of view of maintaining and exte
You should really give Gradle a try. It's pretty straightforward.
Le 21 juin 2016 23:40, "Mr Andersson" a écrit :
>
>
> On 06/21/2016 10:39 PM, Jochen Theodorou wrote:
>
> On 21.06.2016 09:04, Mr Andersson wrote:
>
> Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of
> compilat
I don't think the dynamic nature of Groovy is in general regarded as
the weakest point of Groovy right now. However, I believe a fully
static Groovy may still be preferrable than the dynamic Groovy, mostly
from the point of view of maintaining and extending Groovy in the
future, without financial s
23 matches
Mail list logo
