Doru, On 16 Jul 2013, at 22:24, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
The recently announced cool tutorial on using Zinc made me read the Zinc code in a bit more detail. I must admit, it makes for a nice read.
Thanks.
In the process, I stumbled across:
knownHTTPMethods ^ #( "Standard HTTP 1.1 Verbs" GET PUT POST DELETE HEAD TRACE OPTIONS CONNECT PATCH "WebDAV verbs" PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK)
I would propose to model these as classes (inheriting from ZnRequestMethod).
If we would have such a hierarchy, then the following code:
ZnSingleThreadedServer>>handleRequest: request ... request method = #HEAD ifTrue: [ response clearEntity ].
Could become something like:
ZnSingleThreadedServer>>handleRequest: request ... request method clearEntityForSingleThreadedServerResponse: response
ZnRequestMethod>>clearEntityForSingleThreadedServer: aResponse "nothing"
ZnHeadRequestMethod>>clearEntityForSingleThreadedServer: aResponse aResponse clearEntity
What do you think?
It is super exciting that you are willing to have a look at some of the Zinc internals and are giving feedback and suggestions. I know that some parts of Zinc could be improved quite a bit. For example, when I started in 2010, I tried to not write any extension methods anywhere. Hence there are some rather silly utility classes - that has to be changed. In other places, an even stronger object oriented approach (using full delegation, ask don't tell), could improve things. I absolutely like double dispatch, but sometimes I come across lots of methods on basic classes that are presumable used for double dispatch, but don't make sense on their own or for anyone else. I don't know, but somehow it feels to me as if that should be a criterium. Unless of course you consider an *extension as totally private. Now, for your specific suggestion, yes it could make sense. There are 4 places in the current code base where that would be useful: - ZnClient>>#executeRequestResponse - ZnClient>>#prepareRedirect - ZnClient>>#curl - ZnSingleThreadedServer>>#handleRequest: The other cases are related to HTTP dispatching or routing in delegates (objects implementing #handleRequest: like ZnStaticFileServerDelegate). In this last case the hierarchy could be useful too, but I am not 100% sure. You see, HTTP dispatching/routing is multi-dimensional: it is done on HTTP method, but also on the URL, query parameters or headers. I envision an additional generic dispatch for handling requests based on their method. Like this: MyApp>>handleRequest: request request method dispatchRequest: request on: self ZnGetRequestMethod>>dispatchRequest: request on: object object handleGetRequest: request ZnPutRequestMethod>>dispatchRequest: request on: object object handlePutRequest: request [..] MyApp>>handleGetRequest: request MyApp>>handlePutRequest: request The problem is that there are quite a lot method types, hence it would require the implementation of many #handleXXXRequest: methods on the target. This could be solved by inheritance, with empty implementations, but right now handlers do not have to subclass some specific class, and I like that. So the 'fanout' would be 'wide'. I don't think this can be solved with Traits either. Some trick with #respondsTo: or catching DNU could overcome this 'problem', but is a more of a hack. This idea of 'we will send some message to you if you implement it' is I believe quite common in Cocoa/Object-C for example. Do you understand what I mean ? What do you think ? Sven PS: I am going to take a short one week holiday and I am planning to keep my computer closed, so I am off the grid ;-)
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."