On 08/23/2011 06:20 PM, Bill Burke wrote:
>
>
> On 8/23/11 7:19 AM, Marek Potociar wrote:
>>
>>
>> On 08/22/2011 05:49 PM, Sergey Beryozkin wrote:
>>> I was actually looking forward to Bill's revision being approved too - thought there was some agreement about
>>> finalizing the chain with get()/etc in most cases and generally I thought it was step forward toward the
>>> simplification of the client api.
>>
>> While we agree with Bill in the end result (i.e. what the end-user sees in code), we seem to differ in the solution.
>> Bill prefers API simplicity over consistency. I prefer API consistency over simplicity, esp. in case of a fluent API.
>> When it comes to the ease of use, both versions are comparably easy to use.
>>
>
> The thing is, I doubt anybody will care if its 100% fluent. The previous version was already pretty much 99% fluent.
> Even that 1% difference was up for debate, IMO on whether it was "fluent" or not.
The problem was with the verb not being at the end. It sure had to bother you too as you tried to address it in your
proposal.
>
> Easy-to-use needs also to be easy-to-learn. You can't learn this API looking at the javadoc, which is a huge minus IMO.
>
It's just a matter of how you approach writing the javadoc. See the Guice Binder javadoc I referenced in my other reply.
Fluent APIs are known to have a natural problem with being described only by the plain listing of classes and their
methods descriptions. That's nothing new, it's a known fact. To quote Martin Fowler:
"One of the problems of methods in a fluent interface is that they don't make much sense on their own. ... It's only in
the context of the fluent action that it shows its strengths. One way around this may be to use builder objects that are
only used in this context."
Marek