On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote: > Let me clarify. Right now, you've a wrapper hierarchy that is totally > distinct from the original request hierarchy. You *could* allow everything > wrapped with HttpRequestWrapper to allow expect/continue, in which case you > lose the ability to have specificity for different kinds of wrapped > requests. Or (much better) you could have all HttpRequest objects have a > "supportExpectContinue" method, which in the wrapper would wind up calling > the embedded request's supportExpectContinue method. Seems much better, no? >
Why is exactly instanceof bad or less flexible? It enables certain requests to provide optional behavior such as ability to enclose a request entity, which by the current official HTTP spec applies to POST and PUT _only_. So, what is better, round or green? Oleg > Karl > > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <[email protected]> wrote: > > > >>>>>> > > Are you sure about that? What would this method do for GET requests > > given than those requests are not even supposed to enclose an entity? > > <<<<<< > > > > It would return false for any request implementation that did not support > > expect-continue, of course. > > The advantage of this kind of structure is that it does not rely on the > > implicit instanceof operator, but rather an explicit method implementation, > > so it is clearer (and more flexible). > > > > Karl > > > > > > > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <[email protected]>wrote: > > > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote: > >> > FWIW, a better way for this kind of thing to be done would be for the > >> > request object to have a method, e.g. "supportsExpectContinue()", that > >> you > >> > would call, instead of relying on class names and hierarchy ... > >> > > >> > >> Are you sure about that? What would this method do for GET requests > >> given than those requests are not even supposed to enclose an entity? > >> > >> Oleg > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
