Sergei, I might try to find time shortly to produce a spike of a
slightly improved transform similar to MapArguments. Are you happy for
me to use parts of yours if needed?
Cheers, Paul.
On Wed, Oct 5, 2016 at 12:39 AM, Sergei Egorov wrote:
> Hi Graeme,
>
> FYI a few years ago I created an AST tr
On Thu, Oct 6, 2016 at 10:45 AM, Jochen Theodorou wrote:
>
>
> On 06.10.2016 09:16, Cédric Champeau wrote:
>>
>> I prefer to support different _methodMissing_ methods taking different
>> arguments, because they can participate in method selection and return a
>> more specific type.
>>
>> Something
On 06.10.2016 09:16, Cédric Champeau wrote:
I prefer to support different _methodMissing_ methods taking different
arguments, because they can participate in method selection and return a
more specific type.
Something to consider too: @DelegatesTo is not on par with
@ClosureParams wrt to the t
I prefer to support different _methodMissing_ methods taking different
arguments, because they can participate in method selection and return a
more specific type.
Something to consider too: @DelegatesTo is not on par with @ClosureParams
wrt to the types it can express. In particular, it doesn't h
Hi Jochen,
Yeah that sounds good, I like the idea of an interface or trait, that
makes it easier to optimize the performance of the compiler. I also
like the idea of avoiding the overhead of closure method dispatch. To
make it more flexible we could like I said allow specifying the
delegate via @D
On 05.10.2016 21:41, Graeme Rocher wrote:
[...]
Then for (2)... methodMissing(String, Closure) will not get you anywhere in
terms of type checking. This is for methods "foo{...}" or "bar{...}", where
bar and foo are the String. If you write foobar instead, there is nothing
preventing compilation
On Wed, Oct 5, 2016 at 7:33 PM, Jochen Theodorou wrote:
> On 05.10.2016 08:13, Graeme Rocher wrote:
> [...]
>>
>> So again let's revisit the benefits of this change:
>>
>> 1) You can write classes annotated with @CompileStatic and use
>> builders without having to compromise the design of your cod
Hi Graeme and thanks for the proposal!
I think we should be very clear about the objectives here, and very clear
about how to write such builders. In particular, in the past, we've
explicitly discarded the idea of doing "Scala-like" dynamic in compile
static mode, because the types are important.
On 05.10.2016 08:13, Graeme Rocher wrote:
[...]
So again let's revisit the benefits of this change:
1) You can write classes annotated with @CompileStatic and use
builders without having to compromise the design of your code
2) You can get type checking for non-builder methods if concrete types
Hi Jochen,
Thanks for the interesting analysis of dynamic dispatch via builders
in dynamic Groovy! I feel though the conversation is getting slightly
derailed, this is not about dynamic Groovy this about statically
compiled Groovy. Let us revisit the goals:
1) Allow builders to be used when the c
On 04.10.2016 18:00, Graeme Rocher wrote:
[...] If you combine this
will my other proposal around allowing delegates to on maps you can
see that you could implement markup builder for static compilation
mkp.html {
body {
div id:"test"
}
}
ok, let us assume mkp is a @
The use case is really around builders, not so much around regular objects.
Builders don't really use return types that much, but if you did want
return type information we could support methodMissing that return a
concrete type. Typical builder code that could be statically compiled
def json = n
On 04.10.2016 16:32, Graeme Rocher wrote:
[...]
I would like to propose adding the ability to create builders that can
be statically compiled by adding a capability similar to Scala's
Dynamic:
https://issues.apache.org/jira/browse/GROOVY-7957
the question is what you really gain from that...
Interesting. Also related to this, I wrote a type checking extension
that makes it possible to statically compile StreamingJsonBuilder by
delegating missing methods to invokeMethod:
https://github.com/grails/grails-views/blob/master/core/src/main/groovy/grails/views/compiler/BuilderTypeCheckingExt
Hi Graeme,
FYI a few years ago I created an AST transformation for MapArguments:
https://github.com/bsideup/GroovyMapArguments/blob/master/src/test/groovy/ru/trylogic/groovy/mapargs/MapArgumentsTest.groovy
Might be helpful :)
BR,
Sergei
On Tue, Oct 4, 2016 at 5:33 PM Graeme Rocher
wrote:
> C
15 matches
Mail list logo
