On Tue, Oct 14, 2025 at 12:37 PM Richard Eckart de Castilho <[email protected]> wrote:
> Thanks for the proposal. > > > On 13. Oct 2025, at 17:16, Andrea Del Bene <[email protected]> wrote: > > > > > https://github.com/apache/wicket/compare/master...bitstorm:wicket:lambda_spicing > > In your proposal, there are two classes "BehaviourBuilder" and > "LambdaBehavior". The first always builds the latter. I would have expected > a "LambdaBehavior.builder()" factory method to create the builder and the > builder being an internal class of the "LambdaBehavior". > Right. Basically I like to keep LambdaBehavior available for those who want to use directly in their code > > What I really like in your proposal is that all callbacks get the > component as an argument, even "visibleWhen" and "enabledWhen". > > So an example using your approach: > > import static BehaviorBuilder; // let's discount this line > > component.add(BehaviorBuilder.newBuilder() > .visibleWhen(this::isEasterEggFound) > .enabledWhen(this::isEasterEggTriggered) > .build(); > > In the current implementation of "LambdaBehavior" the "visibleWhen", > "enabledWhen" and "onConfigure" methods seem to be mutually exclusive > because they seem to override each other. If the idea is that the user > would add a single "LambdaBehavior" to a component which covers multiple > callbacks, then all of them should be usable. > Yes, in this first implementation I did "visibleWhen", "enabledWhen" and "onConfigure" methods are mutually exclusive. I think we should overcome this limit working an the builder in order to remember the different lambdas set by each method. In this way when we invoke build() we could produce a single LambdaBehavior with the expected behavior. > > I (probably obviously) like the approach I had taken which uses static > factory methods to create anonymous behaviours: > > import static LambdaBehavior.*; // let's discount this line > > component.add(visibleWhen(this::isEasterEggFound)) > component.add(enabledWhen(this::isEasterEggTriggered)) > > Drawback on approach compared to yours is of course that it spams > anonymous behaviour instances - I'm sure people would call that inefficient > (so far, I don't really mind). But on the positive side, I save calls to > creating the builder and finalizing the builder which makes the code quite > a bit less verbose (and I appreciate concise and readable code). > > > https://github.com/inception-project/inception/blob/0d825f3f52909fed1d8699686d2f8536f03e4403/inception/inception-support/src/main/java/de/tudarmstadt/ukp/inception/support/lambda/LambdaBehavior.java#L167-L179 > > Maybe a hybrid/merger of the two approaches (builder + factory methods) > would be viable. > > For sugar on top: > > I found it useful to also have "enabled/visibleWhenNot" and variations of > the "when" methods that take a "IModel<Boolean>" instead of a supplier. > I will try to rielaborate the code when I will have some spare time... Bye!
