I also believe the canonical
def games = Game.findAllByAverageDurationBetween(30, 90)
>
is nothing more than
def games = (new
> Gorm()).executeQuery("findAllByAverageDurationBetween",30, 90)
class Gorm {
ResultSet executeQuery(String query, Object... argos)
//caching logic
}
though Mi
Hi, Edmond
can you give me a case not covered by a typed language? I'm really
curious, because the more I think the more I see modern PL
practice/research has uncovered typed language strengths. These days, typed
languages solve more and more issues traditionally solved with dynamic
languages.
O
As an example, Grolifant is a library for allowing Gradle plugins to
maintain compatibility over wide range of Gradle releases. Currently
this range is Gradle 4.3 - 8.5. Public interfaces are written in Java,
but 99% of implementations are done in Groovy. Anything Groovy & public
is statically
I typically use Groovy in its static mode, and the single biggest value to
me is the AST-transformation system. However, there are cases where I find
dynamic mode very useful.
1. Methods that handle processing for particular subtypes of a base type. I
could do something like a class-based map with
>From the perspective of someone building products that leverage the dynamic
language features, the answers is a resounding YES, plenty of reason to
keep dual type support (both dynamic and static).
Hi,
I was a 4 years user of Grails/Groovy (last year mostly Python). With the
general trend of people moving to static languages, is there any reason
that Groovy needs to stay dynamic?
I see Python having the mypy approach, I see gradle moving to Kotlin and FE
mostly on Typescript.
I understand
