FunctionalApplication.h File Reference

#include "Stroika/Foundation/StroikaPreComp.h"
#include <limits>
#include <optional>
#include "Stroika/Foundation/Common/Common.h"
#include "Stroika/Foundation/Traversal/Iterator.h"
#include "FunctionalApplication.inl"

Go to the source code of this file.

Classes
struct	Stroika::Foundation::Traversal::DirectPushMapEngine
class	Stroika::Foundation::Traversal::FunctionalApplicationContext< T, MAPPER_ENGINE >

Namespaces
namespace	Stroika::Foundation

Detailed Description

STATUS: PRELIMINARY DRAFT.

NOTES:

TODO:

@todo   add demo project so shows how to use (cleaned up versions of the regtest code)
        Maybe something using bignums (don't exist yet) and the multithreaded threadpool
        mapper (doesn't exist yet) - showing how to run multiple IsPrime's at a time in the
        context of this mapping stuff.

@todo   Consider that we COULD implement something like http://underscorejs.org/#pluck
        if we used VariantValue - instead of "T" types. That would have some merrits.

        Also - using that style (along with ObjectVariantMapper) could allow us to have
        the mapping-engine's not be template based - which might make them easier to
        implement (private/.cpp file).

@todo    do impl of pull-based iterator stuff

        (or at least document deisgn basics)
        .. mujst have filter etc funtions not do anything but acuulate lambdas.
        then construct inverted compuation as iterator.

        MAYBE can do by having each piece that reutrns an iterator do the work
        of priducing apull based iteraotr?
            THAT SEEM BEST!

@todo   DOCUMENT/think through the design choice if Map, and Filter etc - MUST return
        items IN-ORDER. By allowing them to return stuff out of order, they CAN
        by implemented much more efficiently. Probaly have two functions - Map and Map_UO
        where they do the same thing but Map_UO is not necessarily ordreed.

@todo   NOTE that DirectPushMapEngine is bad, and we want a pull-based one ASAP.

@todo   Mapper's must be written in such a way that they are smart-pointers nad
        pass data from first call to last.

@todo   Need to simplify usage further. Example usage is too wordy. See if we can better use templates
        and defaulting to make more brief basic filter usage.

@todo   See http://underscorejs.org/#filter - and add filter, and probably others - but not sure what
        to call these (functional helpers?)
        Same for http://underscorejs.org/#pluck

@todo   CONCEPTS!
            o   use std::function<>... with particular arguments to advertise the
                required type signature,
            o   OR use typename FUNCTION - better performance performance - TEST.

        We should verify if there is truely a performance difference, and if there is, then find

Design Overview This code is based in large part on o conversations with kdj 2013-10-05 o

See also

http://en.wikipedia.org/wiki/MapReduce o

http://www.ruby-doc.org/core-2.0/Array.html#method-i-map o

http://underscorejs.org/#reduce o Python/SQL Alchemy (filter chains). o The code is in part based on ideas for pre-release java 8 streams. o http://java.dzone.com/articles/exploring-java8-lambdas-part-1

The gist is to have a MAPPING_ENGINE - which can either do direct applicaiton and buffering, or pull based compuation (where calls are done in final iterator as you pull results) or done with the first case - applicaiton context/buffering - but via thread pools, or some other strategy.

All this is to do the computation for traditional basic functional programming algorithms, like map/reduce, and filters etc.

To use, you simple instantiate a FunctionalApplicationContext object, and then chain together a series of filters. typically, the end result - last filter step - will be to produce an iterable (which can be trivially converted to another container type).

Definition in file FunctionalApplication.h.