[C++-sig] Re: Adding __len__ to range objects

[Joel de Guzman]

Raoul Gough <RaoulGough at yahoo.co.uk> wrote:

> I've had a chance to look at Joel's indexing_suite, and there should
> be quite a lot of overlap in the functionality between indexing_suite
> and the extended iterator_range. I've been thinking about how to
> provide the range-as-iterable support within the indexing_suite
> framework, but it looks like there would have to be some changes to
> the base classes.

Right. This is one of the things that's holding me back to formally
announcing the suite. It isn't as simple as it started out to be
anymore. It is very useful as it is, but the bottomline is that more 
experience with the sub-framework is needed to ascertain that the 
interface will hold. Sure enough, when I added the map-indexing
suite (just recently), the interface needed to be changed.

> I'm basically considering an indexing_suite-derived class template
> that would use two iterators for construction and provide only the
> relevant support functions (from __iter__ alone for input_iterators
> through to __getitem__ and __setitem__ for random access iterators
> with non-const value types). The problem is that the indexing_suite
> base classes assume that all container functionality is always
> present, all the way up to __delitem__ (impossible for
> iterators). Thus, it is currently unsuitable for use with iterator
> pairs, especially if one considers const_iterators. For instance, the
> following doesn't come close to compiling:
> 
>   boost::python::class_<std::vector<int> > ("Vector")
>     .def (boost::python::vector_indexing_suite<std::vector<int> const>());
> 
> For obvious reasons (note the const qualifier). I haven't got far
> enough to see how many changes it would require to allow containers
> with less functionality than is currently assumed. Maybe Joel has some
> comments about the feasibility of this idea?

I've already considered wrapping iterator ranges. I would appreciate it a lot 
if you are interested to help. As to how many changes it would require to 
allow containers with less functionality, not much. Right now, I have factored 
out 1) proxyability and 2) slicability protocols. I think what needs to be 
factored out, in addition to above are 3) resizability and perhaps 4) 
mutability (constness). 

You can see the factored out code in <indexing_suite_detail.hpp> 
(see no_proxy_helper, proxy_helper, slice_helper and no_slice_helper). 
The indexing suite chooses the appropriate handler based on some flags 
and the types involved. The same system will need to be set in place to 
support resizability and mutability.

Is it feasible? Of course ;-)

Cheers,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net