From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2003-09-12 18:42:48
Hi Brock,
----- Mensaje Original -----
[...]
>
> > I wanted to hide MPL from the user. Picture yourself a potential
> > average user reading the tutorial and, when it comes to the
> specification> of indices, being referred to the MPL
> documentation! She'd probably
> > be scared away. MPL is terrific, but IMHO is not a library every
> > programmer would want to be exposed to.
> > Besides, the MPL sequence used must be a forward sequence, not
> > every sequence is valid. A lot of technical mess for such a simple
> > application.
>
> On the surface this seems like a good argument, but I really don't
> think we
> want every boost library that needs typelists to roll their own
> just so the
> users don't have to see the MPL. If you want to hide the MPL and
> keep the
> user from having to choose a container you could use a using
> declaration to
> bring mpl::vector in to indexed_sets.
>
Well, there's an additional detail for aliasing these MPL sequences
as I do. Not only index_list is an MPL sequence, but also the
class tag<> for specifying tag names for a given index. Now, if
I drop the alias in index_list for consistency I'd have to do the same
in tag. But this cannot be done easily. Index specifiers unique
and non_unique accept either of the following two instantiantion
styles:
[non_]unique<KeyExtractor,Compare=less<KeyExtractor::result_type> >
[non_]unique<TagList,KeyExtractor,Compare=less<KeyExtractor::result_type> >
At first, this seems like it cannot be done, but in fact it can with
some MPL magic: the trick lies in accepting (at compile-time) up to
three template parameters and determining whether the first is
a tag list or not. This check cannot be (easily) done if TagList is just any
MPL forward sequence, so tag<> has some internal "markers"
to help do the job.
I hope I made myself clear, the issue is rather messy. Conclusion
is that I'd rather keep these aliases. I'm open to discussion, though :)
>
> > If there's some consensus about this being desireable, it can be
> > plugged into the library in a matter of minutes.
>
> I think it's a good idea. Macros are better than redundancy IMHO.
>
I'd like to have more opinions on this. Many boosters are macro
hackers for legitimate reasons.
>
> Good luck! FWIW, I just put together a 'remote_function' library
> that uses
> a similar naming technique:
>
> struct get_widget_count;
> struct set_widget_name;
>
> typedef mpl::list<
> named_function<get_widget_count, int ()>,
> named_function<set_widget_name, void (int,std::string)>
> > widget_functions;
>
> remote_function::client<widget_functions> client(ip_addr, port);
>
> cout << "Num widgets: " << client.call<get_widget_count>() << endl;
>
> client.call<set_widget_name>(2, "number 2");
>
Looks good! What is the library aimed at? Planning on boosting it?
> I wonder if there is a name for this technique. Maybe some day
> we'll be
> able to do true compile time strings other than:
>
> boost::mpl::vector_c<char,'h','e','l','l','o'>
>
No standard name that I know of. We could call it "tagged types" :)
Best,
Joaquín M López Muñoz
Telefóinca, Investigación y Desarrollo