On 28.04.21 03:43, Christopher Smith wrote:
This would be both expensive and problematic with static mode, which is
what I use almost exclusively for production code.
On Tue, Apr 27, 2021, 20:26 Remi Forax mailto:fo...@univ-mlv.fr>> wrote:
[...]
It may be simpler to have a conversion from
Is there any reason that these cannot exist side-by-side as extension methods?
If they are safe to co-exist, then you can create each of the alternatives in
turn within a sample project and try them out. The extension method mechanism
is open and available.
public static List collect
The "side by side" approach is my second option; the only significant
downside is an increase in the surface area of the extension landscape. I
think Jochen excellently described the distinction of some cases (`with`)
where Closure awareness is still needed for reasons of delegate
manipulation, and
For any DGM that accepts Closure but does not use closure delegation or
multiple closure param signatures, we could mark the Closure version deprecated
and add an @FunctionalInterface equivalent. Existing code that uses closure
literals or method pointers should be okay. There may be one or tw
My case for `with` and `tap` is that in both cases they're immensely
useful as general pipeline operations, and being able* to use
`with(Foo::transform)` but not `with(Foo.transform(param))` is
inconsistent and has been an in-real-use frustration for my current
project. Where the Closure is explici
It is best IMO to open a JIRA ticket first so that discussion and metadata can
be tracked. Beyond that, opening a pull request on github with a link back to
the ticket should suffice. The ticket prevents surprise when a pull request
shows up. And I'd suggest starting with a small change first
It would be convenient to be able to use the convention of "use
parentheses on a function-like object" with functional interfaces; for
example, if a variable is declared as type Function, to have
`myVar(3)` run `myVar.apply(3)`. Is there any chance this would be
practical, or would its semantics be
