On 05/23/2011 02:17 PM, Bill Burke wrote:
>
>
> On 5/23/11 6:00 AM, Marek Potociar wrote:
>> Hi Bill,
>>
>> I think this is very similar to the changes I have currently in my local sandbox that I have made based on the EG
>> feedback so far.
>>
>> There are few differences:
>>
>> - I like the way you simplified the WebResource API and gave it more constrained purpose
>>
>> - your proposal is full of interfaces. I like it for it's cleanness, esp. while still without javadoc :-), but do we
>> really want to stick to these interfaces forever without the ability to add any new methods?
>>
>
> Eh, I'd only write Javadoc if the proposal was gonna be taken seriously. I don't understand your point of not being
> able to add methods though. Why couldn't you with an interface?
Because adding a method to an interface breaks BW compatibility for anyone who implemented the interface in it's earlier
version. It's the same issue that we have today with core.Request - IMO we cannot just go and add new methods to produce
a unified interface suitable for both client and server side as well as for the filters/interceptors.
>
>> - I don't see how you plan to instantiate the Client
>>
>
> I couldn't decide whether it should be RuntimeDelegate or a ClientRuntimeDelegate. The latter of which we might want to
> have so that we could separate client and server runtimes.
>
>> - the need for the extra .execute() and .resolve() method is something I find redundant
>>
>
> It was either those, or an explosion of put, post, get methods that returned a ClientResponse or a entity body type. I
> don't mind either way.
>
>
>> - your request builder pattern can lead to "illegal" states which I find really unacceptable. The final API simply
>> cannot let me write this code:
>>
>> ClientRequest request = client.request("http://localhost:9095/customers/{id}");
>> ClientResponse response = request.pathParam("id", 123).execute(); // which HTTP method was executed?
>>
>> The above code is IMO the tax for the reduced number of classes in the proposal. Also the fluent builder API suffers
>> greatly. In the days of IDE being the prevalent coding tool, I want the API provide the best code completion possible
>> and I want to let user to write the fluent code that will *not* allow for this:
>>
>> ClientRequest request = client.request("http://localhost:9095/customers/{id}");
>> ClientResponse response = request.get().pathParam("id", 123).put().accept("text/plain").post().execute();
>>
>> Anyway, seems to me that we are on the same page in the most important aspects of the API. Let me finish my changes so
>> that I can push the latest version to the public repo.
>>
>
> TBH, I don't see your point at all. You'd have the same issues with a tradional Builder pattern. Maybe some code on a
> better way would make it clearer for me?
See the Guice Binder API:
http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/Binder.html
It uses multiple interfaces/classes to control the accessible methods. That's what I have in mind.
>
>> Can I take your samples code and rewrite it to fit my version to have a better way to compare and pick the best of the
>> two worlds?
>>
>
> Sure! I just want to get the best API possible and I'm not known for always having the cleanest API.
Ok, thanks a lot.
Marek