Hi,
no confusion on my side either - regarding lambdas at least :P.
> lines of code is not the only metric for a good API.
Lines of imports is a good metric too, and this doesn't look to good for
the Lambdas class :/.
> These methods are trivial for anyone to implement
Yes and everyone will probably do so anyway because there are always
special requirements and needs for these factories.
Have fun
Sven
On 08.02.2017 09:42, Martijn Dashorst wrote:
It is that your trivial use case is not my trivial use case and that
we will end up with a 100,000 trivial use cases.
And no, confusion is not the big issue (though for onsubmit+onerror it
is) but creating a good API is hard. It takes time and understanding.
Minimizing lines of code is not the only metric for a good API.
Just as using inheritance/annotations/generics for everything is bad,
introducing factory methods everywhere will not age well.
These methods are trivial for anyone to implement and should we reach
the conclusion that we actually need the factory methods in core, it
is trivial to refactor them towards the Wicket supplied factories.
Are the factory methods in the way? Yes they are, because once we add
them, we can't evolve them without adding many more (introduce bloat)
or having to wait until a new major release.
Martijn
On Tue, Feb 7, 2017 at 11:40 PM, Martin Grigorov <[email protected]> wrote:
Hi,
These methods are factories for the trivial use cases where nothing else
needs to be overridden but the action method (methods, when there is
onError()). They do help to reduce the verbosity!
There are plenty of those cases. You can see many usages in
wicket-examples. I have used such methods from wicketstuff-scala in one of
my projects in the past and I use similar ones in a project with Kotlin now.
A builder that provides methods like onConfigure(), onComponentTag(),
onDetach(), ... would look really strange!
Who will use it instead of just creating a (inner) class ?!
But if those factory methods confuse core developers then they will be even
more confusing to normal users :-/
0 from me.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Feb 7, 2017 at 5:07 PM, Martijn Dashorst <[email protected]
wrote:
All,
I want to remove all component factory methods that are added for lambda's.
My reasoning is that:
- removing them in 8.x (x > 0) is impossible
- adding them in 8.x (x > 0) is trivial
- we currently don't have a way to know what good idioms are
- having these factories push (new) developers to use the wrong idiom
- factory methods don't allow for additional overriding, thus a
combinatorial explosion of API
- I tend to think that builders are better suited as component factories
Because it is trivial to re-introduce these factories or their
replacements at a later time, I propose to remove them now and figure
out in our actual applications what works, and what doesn't. I also
think that just doing the conversion from W7 to W8 isn't enough to
figure this out.
Example 1:
Button.java has two factory methods:
Button#onSubmit(String, SerializableConsumer<Button>), and
Button#onSubmit(String, SerializableConsumer<Button>,
SerializableConsumer<Button>)
It is not possible to see without resorting to parameter naming,
hovering etc to see which functionality is bound by which parameter. I
find the naming confusing: onSubmit and onSubmit.
Example 2:
Behavior.java has two factory methods:
Behavior onTag(SerializableBiConsumer<Component, ComponentTag>)
Behavior onAttribute(String name,
SerializableFunction<String, CharSequence> onAttribute)
These achieve basically the same functionality, but other life cycle
events of Behavior don't have factory methods. NOR should they.
Example 3:
Lambdas.java has many factory methods, most of which are better
implemented by just using an anonymous inner class. For example,
Lambdas.link: often times you need to override onconfigure or
oncomponenttag as well as onclick.
Martijn
