Hi Dean,
2009/11/17 Dean Michael Berris <[email protected]>
>
> > 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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Cpp-netlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
