On Oct 6, 11:51 pm, "Hans Huebner" <[EMAIL PROTECTED]> wrote:
> 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?

I'm not sure if this helps, but in my Compojure project, I build up
response objects based on the type of the object being returned.

(GET "/" 200)   ; returns HTTP code 200
(GET "/" "Hello")    ; adds to the response body
(GET "/" {"X-Header" "something})    ; adds a header
(GET "/" (new Cookie ...))    ; adds a cookie to the response
(GET "/" (new File ...))    ; streams a file to the response
(GET "/" [200 {"X-Test" "Foo"} "Hello"])    ; vector combines multiple
effects

Maybe you could take a similar approach with your xlightweb interface?

(post-url "http://example.com"; {:name "blah"} (new Cookie ...)
callback-function)

> 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).

This could be useful. I've written some functions that find all of an
object's getters and use them to populate a hash-map, but it would be
nice to have a direct proxy onto the object.

- James
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to