Doru, On 16 Jul 2013, at 22:24, Tudor Girba <[email protected]> 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."
