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

[Dean M. B. <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?

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

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

Right. But to be Boost friendly I think we should move to just detail.
I'll look around and see if I can move those without too much trouble.
;)

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

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

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

Alright, thanks for responding! :)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com