On Thu, Mar 24, 2005 at 05:02:37PM +0100, Thorsten Ottosen wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:umzstxh18.fsf@boost-consulting.com... | "Eric Niebler" <eric@boost-consulting.com> writes:
| It's not an entirely different argument. Peter was saying that once | you publicize the customization point, it no longer "belongs" to the | library. Imagine what happens if some other library wanted to use the | same range concept, but not depend on Boost itself. Either they'd be | picking a new ugly name for a customization point with identical | semantics :( or they'd be using the name "boost_range_begin" in code | with no Boost relationship in sight :(. | | As my wife's co-worker says, "it's a two-headed sword" ;-) | | For that reason, it might be better to use something like | "iterator_range_begin" that has a hope of becoming lingua franca like | swap. At least that's how I understand Peter's argument.
Hm.. yeah...I guess you're better at expressing my point than I myself :-)
iterator_range_ seems to be a good prefix.
What do you say, Eric, do you like iterator_range_begin() etc?
Why iterator_range_? I'm not sure it this is the best, since there is already a class named iterator_range and such a naming might lead to a confusion about the affinity to this class. IIRC, when Boost.Range was accepted as a proper name for this library, it was also accepted as a name of the concept. So why not stick to the simple range_begin() ? I might be missing something? Regards, Pavol