Hi Marijn,
>often times you need to override onconfigure or oncomponenttag as well
as onclick
I completely agree with your argument. The recent pull request for even
more factory methods made me think about this too.
+1 to remove all component factory methods
Thanks
Sven
On 07.02.2017 17:07, Martijn Dashorst 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
