ocals or similar. The signature could also be used to
> restrict the type of the expression allowed, although in most cases I’d
> expect Object or a “T” to be used.
>
>
>
> Jason
>
>
>
> *From:* Sergei Egorov [mailto:bsid...@gmail.com]
> *Sent:* Friday, September
ost cases I’d
> expect Object or a “T” to be used.
>
>
>
> Jason
>
>
>
> *From:* Sergei Egorov [mailto:bsid...@gmail.com]
> *Sent:* Friday, September 23, 2016 9:27 AM
> *To:* us...@groovy.apache.org; dev@groovy.apache.org
> *Subject:* Re: Macro methods proposal
>
>
restrict the type of the
expression allowed, although in most cases I’d expect Object or a “T” to be
used.
Jason
From: Sergei Egorov [mailto:bsid...@gmail.com]
Sent: Friday, September 23, 2016 9:27 AM
To: us...@groovy.apache.org; dev@groovy.apache.org
Subject: Re: Macro methods proposal
Hey Jason
Hey Jason,
Left a comment on #3.
Yes, the method signature of Macro methods is not the same as the call
site. But, for the given call site, IDE can easily determine the signature,
and I'm pretty sure it has all the information already. Plus, this is a new
language feature anyway, so IDE will have
This is a really cool idea, especially I like the idea of the compile-time
checked ORM example. I wonder whether or not the use in simple cases is
productive given JIT inlining and branch prediction when branching on a
constant, and decided to phrase that question in an issue
https://github.com
