You're right, but we're down to enumerating special cases where this can be
made to work without using a declared type, and that seems fragile. It's
how you get massive pitfalls like the "runtime object implements Map"
situation we have now.
On Thu, Apr 29, 2021, 14:03 Remi Forax wrote:
>
>
> --
> De: "Christopher Smith"
> À: "dev"
> Envoyé: Jeudi 29 Avril 2021 19:38:27
> Objet: Re: () call-type syntax for functional interfaces?
> Also an object implementing multiple functional interfaces. In dynamic mode,
> you
> wouldn't know which method to invoke.
if that object is a lambda proxy,
Also an object implementing multiple functional interfaces. In dynamic
mode, you wouldn't know which method to invoke.
On Thu, Apr 29, 2021, 12:34 Jochen Theodorou wrote:
> On 29.04.21 15:32, Christopher Smith wrote:
> > Sure, this is theoretically possible (though many functional interfaces
> >
On 29.04.21 15:32, Christopher Smith wrote:
Sure, this is theoretically possible (though many functional interfaces
aren't annotated), but the convenience I'm asking about would have to be
compile-time, because it would depend on the declared type (which is
part of why I suspect it might not even
Sure, there are some glitches still, but that's why I said that even so
it's a net boost, and I have been using it exclusively since I had the
choice.
On Thu, Apr 29, 2021, 10:56 OCsite wrote:
> Christopher,
>
> On 29 Apr 2021, at 16:57, Christopher Smith wrote:
> Parrot has reduced my frustrat
ANTLR provides reasonably good error messages most of the time, but
sometimes you have to tweak error handling a bit (in this case, searching
for some more meaningful context to report), and/or refactor the grammar in
a way that causes error reports to be more accurate.
On Thu, 29 Apr 2021 at 17:5
Christopher,
> On 29 Apr 2021, at 16:57, Christopher Smith wrote:
> Parrot has reduced my frustration levels about 15% across the board
did it indeed? Weird. In my case, the very opposite is true; compare please
e.g. the problem outlined below (which applies in 3.0.8 just as well) — it
makes f
Yes, this type of thing is possible. I think it would be limited to STC or SC
since you would need to know the type of the receiver.
org.codehaus.groovy.classgen.VariableScopeVisitor#visitMethodCallExpression is
the bit of code that sees "var(...)" and replaces it with "var.call(...)".
Maybe
My sympathies! Eclipse warts and all, Parrot has reduced my frustration
levels about 15% across the board.
On Thu, Apr 29, 2021, 09:50 Milles, Eric (TR Technology) <
eric.mil...@thomsonreuters.com> wrote:
> Understood. Just wanted to make note of something anyone could use now.
> New extension m
Understood. Just wanted to make note of something anyone could use now. New
extension methods may only be available in Groovy 4. Myself, I'm still stuck
on Groovy 2.5 and I get tickets all the time about keeping Groovy 2.4 supported.
From: Christopher Smith
Sent: Thursday, April 29, 2021 9:3
Yup, those workarounds are effective, but they essentially consist in
wrapping the cheap functional interface into an expensive closure even when
there's no value-add. The inverse approach of defining the API to take the
interface and making the closure implement it requires handling that's
already
Here are two alternatives that should work right now:
UnaryOperator multiplier(int multiplicand) {
return x -> x * multiplicand;
}
List list = [1, 2, 3]
list.collect(multiplier(2)) // fails
list.collect(multiplier(2).&apply)
list.collect(this.&miltiplier.curry(2))
-Original Message
Sure, this is theoretically possible (though many functional interfaces
aren't annotated), but the convenience I'm asking about would have to be
compile-time, because it would depend on the declared type (which is part
of why I suspect it might not even make semantic sense in the underlying
dynamic
Sorry if I might be teaching people to suck eggs, but you can discover the
functional method of a functional interface through reflection. It’s a bit of a
lookup but presumably in groovy the results of such lookups do get cached...
I use (reassembled from something that’s a bit more broken up th
Hi,
we have Groovy integrated as a scripting engine in a server software product.
A customer of us reports errors that occur casually in their Groovy scripts
and then persist. Restarting the server JVM seems to fix the error for some
time until it occurs again.
The exceptions that occur are str
That option is not available when using, for example,
java.util.function.Function.
On Thu, Apr 29, 2021, 03:34 Angelo Schneider
wrote:
> Is that not already covered by the call() - method?
> I mean the option to declare a method called `Object call(args)´
> Best Regards
> Angelo
>
> ---
> Angelo
Is that not already covered by the call() - method?
I mean the option to declare a method called `Object call(args)´
Best Regards
Angelo
---
Angelo Schneider
angelo.schnei...@oomentor.de
+49 172 9873893
> Am 29.04.2021 um 02:47 schrieb Christopher Smith :
>
> It would be convenient to be able to
17 matches
Mail list logo
