Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

[Dean M. B. <mik...@gm...>]

Hi Kim,

On Mon, Oct 13, 2008 at 8:45 PM, Kim Gräsman <kim...@gm...> wrote:
>
> On Mon, Oct 13, 2008 at 14:39, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> So with every template that needs a new tag, but shares traits with
>>> existing classes/templates (typically string, ostringstream, char_),
>>> we have to duplicate these definitions.
>>>
>>
>> Do you really need a new tag?
>
> Nope, I don't think so, I was just wondering whether this was the
> issue. I got confused with the http::message_tag.
>

Okay. :)

>> The reason we have a http::message_tag is because there are traits
>> supported by http::message_tag that don't support the default_ tag.
>> It's also a point of customization intended for extension -- so if you
>> want a different storage mechanism for HTTP Messages (like unordered
>> multi-maps for headers, etc.) then you create your own tag and
>> specialize the traits you want to support explicitly.
>
> Yes. But since that tag will be used throughout the implementation,
> passed on to basic_request, basic_message, etc., I'd have to
> specialize all traits for the new tag, even if I'm only changing one,
> right? I think that's where my ability to picture this breaks :)
>

Actually, not really -- or as far as I recall, not at all.

Consider the example below:

template <class Tag>
struct string {
  typedef std::string type;
};

template <>
struct string<tags::wide_default> {
  typedef std::wstring type;
};

If you really needed to customize with your own tag, then you can
override the default implementation (unspecialized version). :-D

>> I'd even think we should promote the traits for the message class to a
>> higher traits namespace, to be (re)used throughout the project. ;-)
>
> Right, I think that makes sense, that was my original problem.
>

Okay. In the meantime, I think it's merely a matter of including the
correct traits from network/message/traits and then in the future
doing a more far-reaching refactoring of the source. :-)

>>> Does that even make sense? :)
>>
>> I think I'm still missing details as to why you need a separate tag
>> apart from the default_ tag that's already available.
>
> I don't think there's a reason. I think I'm beginning to see how this
> fits together, but it's still a little blurry :)
>

Okay. I hope the above example helps. :-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.