|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk