Re: Java discovers map

tar@xxxxxxxxxxxxx (Thomas A. Russ) writes:

This set also has the nice property that it is easily extensible to
iterators that have a structure that is more than just a value.

This idea is satisfied by Property Maps¹ that separate iteration from
value access. A single iterator can then point into any number of
property maps, much like a CLOS class is a key into any number of
generic functions.

Property Maps are central to the Boost Graph Library. The separation of
iteration and access contributes to the refinement of the iterator
categories in the Standard C++ Library, though Property Maps use
iterators only for traversal (calling them "cursors").

As a trivial example, parallel arrays work as property maps for a
decomposed structure:

template <typename PMKey, typename PMVal, typename Iter>
std::ostream& print(std::ostream& os, Iter it,
PMKey pmkey, PMVal pmval)
{
return os << pmkey( *it ) << "->" << pmval( *it );
}


std::string const keys[] = { "foo", "bar" };
int const values[] = { 42, 242 };
size_t iter = 0;

print( std::cout, iter, wrap( keys ), wrap( values ) );


This should print "foo->42".

Here I'm using some hypothetical "wrap()" function that prepares an
array for use as a Property Map. In the Boost Property Map library,
these adapters need not be used explicitly. The Boost library's version
also differs in syntax from the N1873 proposal, including operator[] for
lvalue property maps, but the ideas are basically the same.

To bring this all around, some of my first experiments with specializing
generic functions in CL were motivated by trying to imitate some
property map code I had written in C++.


Footnotes:
¹ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1873.html

--
Steven E. Harris
.