On Wed, Nov 18, 2009 at 8:53 PM, Glyn Matthews <[email protected]> wrote:
> Hi Dean,
>
> 2009/11/17 Dean Michael Berris <[email protected]>
>>
>> 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
------------------------------------------------------------------------------
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
