libs/fusion/todo.txt

   1 ===============================================================================
   2 Copyright (C) 2001-2007 Joel de Guzman, Dan Marsden, Tobias Schwinger
   3
   4 Use, modification and distribution is subject to the Boost Software
   5 License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
   6 http://www.boost.org/LICENSE_1_0.txt)
   7 ===============================================================================
   8
   9 * Document extension::struct_size, extension::struct_member and
  10   extension::struct_assoc_member in extension section.
  11
  12 * Document rationale behind at and value_at and how to choose which
  13   to use.
  14
  15 * Reinstate the function object algorithms
  16
  17 * Break all dependency cycles if there are some more
  18
  19 * Break the view<-->algorithm dependency cycle
  20
  21 * Improve extension docs
  22
  23 * Document sequence/convert
  24
  25 * Consider object equivalent of functions and algorithms (so you can do
  26   transform(iterators, deref()) with needing to put together a wrapper for deref).
  27
  28 * Make algorithms work with mutable data
  29
  30 * Consider segmented sequence / algorithm support
  31
  32 * Consider utility element_ref<Seq,Member>::type thats consts and refs as appropriate
  33
  34 * Improved motivation section
  35
  36 * Expand details of view concept
  37
  38 * Examples, examples, examples
  39
  40 * look at lambda stuff
  41
  42 * Complete the fusion/include/ directory containing a flat list of
  43   include files for all the modules and components.
  44
  45 * The error messages when e.g. the function is not set as const are difficult
  46   to decipher. e.g. transform(s, f) <<- where f has a non-const operator()
  47
  48 * mpl, fusion, container type preserving operations incompatible
  49   -- shall we consider container-type preserving variations of the
  50   functions/algorithms?
  51
  52   How about making joint_view Concept preserving? This way push/pop/front/back
  53   will return a view of the same Concept. - tosh
  54
  55 * map_tie is implemented. It seems not yet documented? - Dan: done now!
  56
  57 * multi_set, multi_map?
  58
  59 * why is insert_range not spelled insert_sequence ?
  60
  61 * Document the new fusion extension mechanisms
  62   ->iterator_facade
  63   ->sequence_facade
  64
  65 * David A:
  66   Wouldn't extension be a lot easier if iterator_base and sequence_base
  67   took (optional) 2nd arguments that specify the tag?  Then you wouldn't
  68   need that whole dance that enables tag dispatching (right?)
  69
  70 * David A: is_iterator isn't documented?
  71   JDG: There is no is_iterator ;) There is is_fusion_iterator, but it should
  72   probably be placed in detail.
  73
  74 * for_each takes the function object by reference to const, so you have to
  75   const qualify operator() and make the data members mutable so you can change
  76   them anyway.
  77   Eric N: IMO, this is a bug in Fusion. There should be an overload of for_each
  78   that takes a function object by non-const reference. Stateful predicates should
  79   be supported, and Fusion should be explicit about where and when predicates
  80   are copied, so that the state doesn't get messed up.
  81
  82 * Make Boost.parameters library's ArgumentPacks a conforming fusion sequence
  83
  84 * Optimize container performance with typeof / compiler defect typeof. In particular
  85   improve the performance of the prototype deque implementation.
  86
  87 * Deque docs if we decide we like it
  88
  89 * Rewrite the whole extension docs section. More formal docs of extension point,
  90   example to use the various facade types, rather than hand coding everything.
  91
  92 * zip optimization - Zip is rather compiler heavy, try and reduce the likelihood
  93   of compilers like msvc7 hitting internal compiler limits
  94
  95 * Document the unused support added to zip for Hartmut.
  96
  97 * Rationalize support/unused.hpp and the ignore stuff needed for tie etc.
  98
  99 * Why do we need to set FUSION_MAX_VECTOR_SIZE when we set
 100   FUSION_MAX_MAP_SIZE? Setting FUSION_MAX_MAP_SIZE should be enough.
 101
 102 tosh:
 103
 104 * Document Incrementable / Single Pass Concepts
 105 * Provide infinity-aware default implementation for Incrementable Sequences
 106
 107   Thoughts: It would probably be cleaner to have infinity conceptually
 108   orthogonal so there can be infinite Bidi/RA/Assoc Sequences.
 109   OTOH it complicates things in way that might not be worth it...
 110
 111 * Implement always_view/always with repetitive_view<single_view<T> >
 112   semantics - using repetitive_view will for this purpose will be way
 113   too much overhead.
 114
 115 ? Functional wrappers for intrinsics/algorithms.
 116
 117 * Rewrite functional benchmark
 118
 119 ==========================================================
 120
 121 From the fusion review (please mark all done items):
 122
 123 The following comments refer to issues that the library authors should
 124 address prior to merging the library into CVS:
 125
 126 * Documentation: Many of the reviewers stated that they would like to
 127    see more tutorial documentation that demonstrates not only what the
 128    particular constructs in Fusion do, but also how they are expected
 129    to be used. A reasonably concise motivating example has been
 130    requested. It has already been pointed out that Fusion is used for
 131    some other boost libraries. A well-developed and self-contained
 132    case study of when and how to use Fusion would be greatly
 133    appreciated. The relationship between this library and the current
 134    Boost.Tuple library, as well as Boost.Mpl, should be discussed. The
 135    reference documentation is quite thorough and detailed comments
 136    regarding them have already been addressed by the authors. However
 137    the notion of "views" requires greater documentation. The
 138    examples in the algorithm sections currently do little more than
 139    demonstrate the syntax by which they can be called. Examples that
 140    more specifically express intent would be a notable
 141    improvement. (see for example Matt Austern's "Generic Programming
 142    and the STL"). In general the documentation would benefit from
 143    copy-editing.
 144
 145 * Several commented on the use of the name "pair" for the fusion type
 146    that has typedefs for two types but only contains the second type.
 147    Although the typedefs and member names are consistent with the
 148    std::pair object, the name "pair" is confusing. The
 149    compile-time/run-time hybrid nature of this library makes it
 150    difficult to find perfect metaphors for constructs in the library.
 151    In this case, it seems better to find a term for this template (and
 152    the concept that it models) that more directly states its purpose.
 153    The name "tag_of" would also benefit from renaming.
 154
 155 * The behavior of Fusion functions in the face of argument-dependent
 156    lookup (ADL) is not well specified. This should be made
 157    explicit in the reference documentation.
 158
 159 The following comments refer to issues that, while not mandatory,
 160 deserve consideration:
 161
 162 * The library name "Fusion", though not arbitrary, says little about
 163    the library's purpose. There is precedent for this within boost,
 164    however. A name change is not mandatory for the
 165    library's acceptance, but it would be worth while for the authors to
 166    consider a more telling name.
 167
 168    Dan - I like the name Fusion, and there is precendent for less direct
 169    library names like Spirit and Xpressive in Boost. (And Boost is not
 170    exactly an explicit name either).
 171
 172 * The mechanism for extending Fusion with new containers and iterators
 173    is complex and involves implementing a number of components,
 174    especially regarding iterators. An adaptation layer that is
 175    analogous to the Boost.Iterator library would be a fine addition to
 176    Fusion.
 177
 178    Dan - Joel added iterator and container adapters, still to be documented
 179    as part of the improved extension docs to be done by me.
 180
 181 * It would be beneficial to supply Boost.Serialization support for the
 182    Fusion container types. I am sure, as mentioned, that the authors
 183    of this library would accept a volunteer to implement this
 184    functionality.
 185