From: Dean M. B. <mik...@gm...> - 2008-09-15 07:37:49
|
Hi Kim, On Mon, Sep 15, 2008 at 3:23 PM, Kim Gräsman <kim...@gm...> wrote: > > I've noticed the cpp-netlib code base uses a couple of idioms that I > don't really get: > > 1) tags -- I (think I) understand tag dispatching, but I don't see a > clear-cut reason to use a tag with the basic_client, for example...? Ok. > Is it just something to group traits around? No. :-) The idea of being able to specialize implementations on traits is a very big extensibility plus. Consider: If you had your own message tag (that's not the same message tag that's provided in the library) where you specialized the behavior of the actual message object(s) -- an example of a streaming/asynchronous message comes to mind -- allows you to either re-use the existing client implementation (basic_client<your_tag, 1, 0>) or extend the implementation such that you have tag-specific behavior (use futures, buffered asynchronous streams, etc.) without compromising existing usage of default-tagged implementations. This is all kept in mind to enable seamless extension using templates. :-) > I think I would have > naively built a message_traits class, that exposed the respective > typedefs, so I don't really see the benefit of the scattered traits > structs. Except maybe for the fact that they _are_ scattered, so they > can be specialized on a case-by-case basis? > The bad part about blobs (or traits grouped together) is that it's hard to extend that design -- you cannot add new traits around tags and designs without running into the 'too many member' problem. Besides, it's also not good design to have 1+ nested types where you only need to access 1. > 2) directives -- I don't see what benefit these added over member > functions on the message... Help? > This is to support the following syntax: using namespace boost::network; http::message msg; msg << header("Header", "value") << header("AnotherHeader", "value") << body("The quick brown fox jumps over the lazy dog."); The directives can also be specialized by tags, so that you can make it do other things based on the tag. This is also built in with extensibility in mind. Using this approach, we get extensibility for free along with a semantically consistent interface to the message framework. > Thanks for any pointers, HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |