On Mon, Oct 6, 2008 at 17:47, James Reeves <[EMAIL PROTECTED]> wrote: > The most important thing I can think of is to remember that your > wrapper doesn't have to be comprehensive. [...]
> So long as people can go back and use the Java API to do the complex > stuff, I figure the best way to approach wrapper libraries is to make > it as easy and as straightforward as possible for people to start > using it. My use case for this library involves a lot of the more complex stuff, so my wrapper actually needs to be comprehensive enough. I will need all asynchronous functionality that I can find, and I will need a lot of the methods that the classes provide. Rather than just moving forward with my application and extend the wrapper as needed, my plan therefore is to first invest enough into the infrastructure so that I won't have to return to it again and again while writing application code, maybe correcting ad-hoc wrapper design decisions and having to redesign things when I was hoping to make progress on the application. Your simple example, creating a wrapper around the http client, really shows off the problem quite well: True, for most use cases, people will just have the library fetch the given URL and be done with it. But what about query parameters, how would the be usefully represented? POST-requests with bodies? What about cookies? If one is lucky, one finds good on the fly solutions, or can get away with a few native API calls intermixed with wrapper invocations. If one is not, there will be existing code using an existing API that needs to be rewritten, and maybe even users that depend on the simplicistic design and now somehow expect you to support it. Thus, I somehow need to either transform much of the whole thing into a functional library, or I need to use the Java API from my application, maybe applying a little syntatic sugar here and there. For the callback interfaces, just using 'proxy' will propably be the easiest, although I will propably go with a 'proxy-fns' macro that expect fns instead of function bodies for the handler - any sizeable application will dispatch to a named function from the interface anyway, and repeating the argument names in the invocation of the function seems redundant. Maybe 'proxy' should work like this in the first place. http://paste.lisp.org/display/68075 has an example of what proxy-fns would do. For object property getters and setters, I would like to be able to read properties using a keyword as the key, similar to hash table access, instead of having to invoke a getter. I would like this to be both lazy and fast at the same time, and as getters might have arbitary performance characteristics, creating a hash table on the fly and populate it by calling all the getters would not be the right thing (also, there would be suprising caching in the wrapper). Thus, what I propably want is a mechanism that establishes the mapping between a keyword and a getter (and setter) method of the class at compile time. Is that a sensible approach? Again, thank you, James, for your input. Your and any additional input is greatly appreciated. -Hans --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
