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

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

Hi Dean,  Thanks for the quick response.

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

> On Wed, Nov 18, 2009 at 8:53 PM, Glyn Matthews <gly...@gm...>
> wrote:
> > Hi Dean,
> >
> > 2009/11/17 Dean Michael Berris <mik...@gm...>
> >>
> >> 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.
> >
>
> Alright. I'll wait for the page. One last try:
>
> Let's say I want to implement a function 'swap' that can be pulled via
> ADL. I would typically write it like this:
>
>
> namespace boost { namespace network {
>
>  template <class Tag>
>  inline
>  void swap(basic_message<Tag> & l, basic_message<Tag> & r) {
>    l.swap(r);
>  }
>
> } }
>
> Without this, I'm going to be stuck with a globally defined function
> 'swap' which I cannot specialize or narrow down to types of messages.
>
> Does this help?
>

Nope, cos that's not the question I wanted to ask :)  I'll try and
reformulate it again when I'm not as distracted.


>
> >
> >>
> >> > 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.
> >
>
> Sure, but what would you name the default tag? Only reason it's
> tags::default_ is because default is a keyword. :D
>
> Even if we have:
>
>  typedef basic_message<> message;
>
> What would you call the tag name that's default in the basic_message
> implementation? And what tag do you dispatch on? :D
>

Yeah, I see.



> >>
> >> > 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.
> >
>
> Let me see if I need to tweak anything in my settings. Have there been
> any filed tickets regarding this assigned to me yet?
>

I don't think so.

>
> >>
> >> > 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.
> >
>
> Aha! Cool. :) Thanks for doing this. I'll look into stabilizing and
> fixing some URI related things with HTTP as I go along. I saw this btw
> using GitG and visualized the whole tree -- we should definitely prune
> some branches when we move to git after 0.4 goes out.
>
>
>
Good :)
Thanks again,
G