Re: [cpp-netlib-devel] Updated 0.4 integration branch

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/11/17 Dean Michael Berris <mik...@gm...>

>
> > 3. I need clarification as to why there should be tags to identify
> different
> > protocols.  I understand the need to specialize templates for strings and
> > header_containers but I can't see why we have, e.g.
> > boost::network::http::message_tags to specialize
> > boost::network::http::basic_message as we do now.  this means we have to
> > provide traits for struct string<http::message_tags> as well as
> > string<tags::default_> which are in fact going to be identical.
>
> The reasoning for this is so that we can have different interfaces for
> the different specializations of basic_message. Although we might
> probably be able to get away with a Message concept which is opaque
> and can be checked/enforced by BCCL, my concern for that would be the
> lack of "specialization" for writing generic algorithms that might be
> able to do tag dispatching. For instance:
>
>  template <class Tag>
>  void foo(basic_message<Tag> const & msg) {
>    bar(msg, Tag()); // use tag dispatching
>  }
>
> This also allows us to specialize some operations on basic_messages:
>
>  template <class Tag, class Transformation>
>  basic_message<Tag> transform(basic_message<Tag> const & msg,
> transformation<Transformation> f) {
>    return f(msg);
>  }
>
> Although this might work with BCCL using opaque types, it's worth a
> shot. Again let me look back at cleaning up the message abstraction
> and algorithms at a later time.
>

It's still not clear.  I'll try and describe my problem in more detail on
the wiki, but it's difficult for me to see the advantages without some
concrete examples.



>
> > 4. I don't like the name, tags::default_.  I added tags::default_string
> and
> > tags::default_wstring, and, while they're more descriptive, I think they
> can
> > be improved.
>
> The intention in my brain for tags::default_ was not just for what
> kind of strings to use, but also for default implementations for
> example of the HTTP client and the basic_message template. The
> default_ tag was meant to be the default implementation for anything
> that was being shipped with the library -- and traits were dispatched
> according to that tag. This allows for using compile-time flags to
> switch the default typedef for boost::network::message from
> `boost::network::basic_message<tags::default_>` to
> `boost::network::basic_message<tags::special>` or something to that
> effect.
>
>
My problem is with the name not the idea, it's ugly (as an aside, as a C++
programmer I'm often very frustrated that names I want to use such as
`default` and `register` are reserved).  The suggestions I gave just weren't
that much better.  Can we do something like
`boost::network::basic_message<>` to indicate the default?  Boost.Random
does something similar to this.


> > 5. Internally, we sometimes use namespace impl and sometimes namespace
> > detail.  We should be more consistent and choose one.
>
> I think personally there's a distinction, but I won't fight for impl.
> In my mind impl:: is supposed to be just for implementations, while
> detail:: can also implement helpers and utility classes, etc.;
> detail::impl:: might make sense but then that would be too much
> nesting even for me. ;)
>
> I like detail and it follows the boost tradition.
>

In either case, I understand both to not be a part of the public interface.


>
> > 6. The implementation of http::message and http::message uses std::string
> >
>
> Yeah, I should change that really. File Trac tickets? :) I don't
> receive emails though, is there something that I should do special to
> get alerts on new tickets filed and assigned to me?
>

Oh I don't know.  I get e-mail alerts but I thought that was set up by
default.


>
> > Please try and run the tests and let me know if there are any other
> issues.
> > Dean and John, perhaps you could be able to see if the updates work with
> > what you're both trying to do.
> >
>
> Is the branch cut from trunk, or was it cut from somewhere else? I'll
> try to merge your changes into my branch first, then come up with a
> patch set or try to merge back the stabilized version into the
> integration branch.
>

Cut from trunk.  And I merged your changes from urllib-dean, so merging them
back should be trivial.


>
> Please expect something within the next couple of days.
>
> Cool.  I won't be able to do much until the weekend.
G