I'd vote for b+v (remove the complicated ones and remove the Lambdas facade)

Have fun
Sven


On 02.03.2017 11:00, Andrea Del Bene wrote:
+1 for v

But I'd also like to move factory methods for components to WicketStuff.
For example we could create something like this:
https://github.com/rodrigouchoa/wicket-lambda

On Tue, Feb 28, 2017 at 9:21 PM, Vit Rozkovec <[email protected]> wrote:

Hi,
why not move all lambdas functionality to wicket stuff..?
This way core stays clean and who wants can use them anyway..

Vit


On 02/28/2017 07:36 PM, Tobias Soloschenko wrote:

I would keep them but try to find good names so that it is clear what
they do.

But you know me - I often create to code intensive APIs ;-D

kind regards

Tobias

Am 28.02.2017 um 19:16 schrieb Sven Meier <[email protected]>:
Hi all,

currently we have 15 behavior factory methods in
org.apache.wicket.lambda.Lambdas, all forwarding to the actual
implementations in different behavior classes.
4 of these methods require two lambda parameters (success- and
error-handler), something which has already been criticized as being
unclear and hard to name well.

This is a vote on what to do with these factory methods in Wicket 8.x:

a) remove them all

b) remove the 4 'complicated' ones (with more than one lambda argument)

c) keep them all as they are

v) remove Lambdas class but keep factory methods in the behavior classes

w) remove factory methods from behavior classes but keep them in Lambdas
class.

We'll need at least 3 binding votes to go from here, let's see what we
can agree on.

Have fun
Sven



Reply via email to