From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-02 02:42:55
On Wed, Oct 01, 2003 at 08:29:15AM -0400, David Abrahams wrote:
> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
>
> >> > "David Abrahams" <dave_at_[hidden]> wrote in message
> >> > news:uekxyrm8n.fsf_at_boost-consulting.com...
> > [snip]
> >> >> Yes, it's important to do it that way for many reasons, not least of
> >> >> which is MPL interoperability.
> >> >
> >> > would it be a sin to have both?
> >>
> >> Yes. ;-)
> >>
> >> What's the advantage?
> >
> > people can choose whatever they like. Some people might think it's more
> > intuitive to write
> >
> > container_traits<C>::iterator
> >
> > than
> >
> > container_iterator<C>::type.
>
[snip]
I'd like to add my 5p to this discussion.
Container traits are supposed to unify access to different containers. That's clear to
must of us:).
In the current version the most tricky part it to select the right container_traits
for the given type. We have handling for some commont container types, and that's it.
The new interface will move this facility to a private namespace and will give
to a user only trait-per attribute interface.
But how the user will be able to introduce a new container? Currently it is enough
to specialize container_traits, but in the new interface she will have to specialize
a whole bunch of traits or to tamper the private namespace.
I don't think the that new interface is useless. As I see, it is important for the
usage with MPL.
However, I don't think that it should be the only option. I would suggest to
leave the old interface as the mainstrem and the new one only as usefull option.
Pavol