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