groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alessio <aless...@gmail.com>
Subject Re: "External" closures, why?
Date Tue, 01 Dec 2015 23:17:17 GMT
>
> should work in any Groovy version. The difference here is that for this to
> work we can use any class being a parent to groovy.lang.Closure plus the
> class itself of course. In the case here I did not give a type, which is
> equal to using the base type of all types in Java and Groovy, which is
> java.lang.Object

Thanks for the clarification, this also seems to go along with what
Jason wrote before.

Could you just confirm if my previous summary below is correct then?
If so I guess I understood what 2.2 introduced ...

  "So before 2.2 the cast was necessary in order to satisfy the method
  signature argument-wise, with a single Object argument being the
  default (and hence not requiring a cast)?"

>
> if you forget about lambdas and function pointers and such for a moment and
> simply think of a while loop:
>
> while (x) { doSomething() }
>
> then you will recognize this as perfectly in synch with the attached blocks
> I mentioned - of course only on the syntax level. On the semantic level
> there is a bit more than that.

Alright, fair enough. This example also reflects what Guillaume
mentioned in a previous reply with his unless() example.

Purely from a personal point of view I'd probably stay away from sugar
coating user-level functions to mimic native language elements as in
the given example but then, I am not a language designer :)

Could you please just let me know if my previous assumption below is
correct as well?

  "it only works if the method expects the closure as ultimate argument.
  In that case it can be appended outside, otherwise not."


Thanks again!

Mime
View raw message