Craig Henderson wrote:
I think we're misunderstanding each other. My point is that if it is an instance of a functor, then the developer may be tempted to presume a state of the object and store instance data. This is invalid as the map task object is created, used and then destroyed. Any attempt to share data between map objects breaks the MapReduce design and scalability
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of joel On 09 August 2009 17:32, joel wrote: properties
(which need to be preserved for loyalty to the MapReduce paradigm and for future multi-machine scalability).
Well that's a problem with any kind of functor anyway. There is the same problem with Boost.Thread where you should be aware of the internal copy of the functor object etc...
I've thought about this a lot, and have concluded that a regular functor *is* more intuitive as it is consistent with other libraries. To that end, I've updated the sandbox with the code changes in the library and sample/test applications as well as the documentation To all users of the library; PLEASE NOTE the Breaking change: map_task and reduce_task now must implement a function operator rather than static methods map and reduce. The functor signatures are the same the previous static methods. Thanks -- Craig http://www.craighenderson.co.uk