/*
 * Project: MoleCuilder
 * Description: creates and alters molecular systems
 * Copyright (C)  2010 University of Bonn. All rights reserved.
 * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
 */

/**
 * \file future.dox
 *
 * Created on: Nov 03, 2011
 *    Author: heber
 */

/**
 * \page future What's to come up next code-wise
 *
 * \section future-refactoring Refactoring the code
 *
 * Here is a list of what pieces of the code should be refactored to make them
 * easier to use:
 * - Fragmentation and related classes: Just generate the keysets and have a
 *  pool of hydrogen atoms that are re-used when creating and writing
 *  fragments. Add and re-add messes up the Id's of the Atom's.
 * - Tesselation and related classes: Especially, the removing and adding of
 *  nodes is not fully (and correctly) implemented, see the regression tests
 *  on convex(!) envelopes (non-convex are working).
 * - all internal, non-atom related information of FormatParser's should be
 *  stored in FormatParserParameters (e.g. AtomData line of tremolo)
 *
 * \section future-extension Extending the code
 *
 * Here the list of what should be implemented to make the code more powerful
 * and just makes sense given the current constructs.
 * - LinkedCell should be owned by the World and internally, such that one
 *  simply may access nearest neighbors (e.g. via Selection of a sphere) but in
 * \f$ {\cal O}(N) \f$ and not naively \f${\cal} (N^2)\f$.
 * - LinkedCell should be updateable. Thus it could listen to World's
 *  notifications when World::AtomInserted or World::AtomRemoved and update.
 *  Hence, it would always be up-to-date. Combined with the Cachable pattern in
 *  CodePatterns realizing lazy evaluation (http://en.wikipedia.org/wiki/Lazy_evaluation),
 *  i.e. when many updates have gathered, we rather re-create the linked cell
 *  structure, this can easily be made very convenient, fast, and powerful.
 * - BondGraph should be updataeable. As above it should listen the Worlds'
 *  notifications and so on (also Cachable ...)
 * - Tesselation should be a Shape: Such that it can be used for Fillings.
 * - Tesselation should be loadable/storable from/to file: One the one hand
 *  this could mean \ref serialization but rather \b .3ds or another file
 *  format such that structures can filled with some external program and
 *  filled with a certain algorithm later-on.
 * - Tesselation: Extend such that the created surface can be pushed away from
 *  the atoms to resemble the molecular surface (http://en.wikipedia.org/wiki/Molecular_surface)
 * - all Actions regarding Filling: Filling should be generalized as to get a
 *  shape and vector of atoms and to do something with it. Especially, not a
 *  new Action but a token that just tells how to fill and a factory pattern
 *  behind it that spits out the algorithm how to do it.
 *
 *
 * \date 2011-11-03
 *
 */