| [f11c23] | 1 | /*
|
|---|
| 2 | * Project: MoleCuilder
|
|---|
| 3 | * Description: creates and alters molecular systems
|
|---|
| 4 | * Copyright (C) 2010 University of Bonn. All rights reserved.
|
|---|
| 5 | * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
|
|---|
| 6 | */
|
|---|
| 7 |
|
|---|
| 8 | /**
|
|---|
| 9 | * \file future.dox
|
|---|
| 10 | *
|
|---|
| 11 | * Created on: Nov 03, 2011
|
|---|
| 12 | * Author: heber
|
|---|
| 13 | */
|
|---|
| 14 |
|
|---|
| 15 | /**
|
|---|
| 16 | * \page future What's to come up next code-wise
|
|---|
| 17 | *
|
|---|
| 18 | * \section future-refactoring Refactoring the code
|
|---|
| 19 | *
|
|---|
| 20 | * Here is a list of what pieces of the code should be refactored to make them
|
|---|
| 21 | * easier to use:
|
|---|
| 22 | * - Fragmentation and related classes: Just generate the keysets and have a
|
|---|
| 23 | * pool of hydrogen atoms that are re-used when creating and writing
|
|---|
| 24 | * fragments. Add and re-add messes up the Id's of the Atom's.
|
|---|
| 25 | * - Tesselation and related classes: Especially, the removing and adding of
|
|---|
| 26 | * nodes is not fully (and correctly) implemented, see the regression tests
|
|---|
| 27 | * on convex(!) envelopes (non-convex are working).
|
|---|
| 28 | * - all internal, non-atom related information of FormatParser's should be
|
|---|
| 29 | * stored in FormatParserParameters (e.g. AtomData line of tremolo)
|
|---|
| 30 | *
|
|---|
| 31 | * \section future-extension Extending the code
|
|---|
| 32 | *
|
|---|
| 33 | * Here the list of what should be implemented to make the code more powerful
|
|---|
| 34 | * and just makes sense given the current constructs.
|
|---|
| 35 | * - LinkedCell should be owned by the World and internally, such that one
|
|---|
| 36 | * simply may access nearest neighbors (e.g. via Selection of a sphere) but in
|
|---|
| 37 | * \f$ {\cal O}(N) \f$ and not naively \f${\cal} (N^2)\f$.
|
|---|
| 38 | * - LinkedCell should be updateable. Thus it could listen to World's
|
|---|
| 39 | * notifications when World::AtomInserted or World::AtomRemoved and update.
|
|---|
| 40 | * Hence, it would always be up-to-date. Combined with the Cachable pattern in
|
|---|
| 41 | * CodePatterns realizing lazy evaluation (http://en.wikipedia.org/wiki/Lazy_evaluation),
|
|---|
| 42 | * i.e. when many updates have gathered, we rather re-create the linked cell
|
|---|
| 43 | * structure, this can easily be made very convenient, fast, and powerful.
|
|---|
| 44 | * - BondGraph should be updataeable. As above it should listen the Worlds'
|
|---|
| 45 | * notifications and so on (also Cachable ...)
|
|---|
| 46 | * - Tesselation should be a Shape: Such that it can be used for Fillings.
|
|---|
| 47 | * - Tesselation should be loadable/storable from/to file: One the one hand
|
|---|
| 48 | * this could mean \ref serialization but rather \b .3ds or another file
|
|---|
| 49 | * format such that structures can filled with some external program and
|
|---|
| 50 | * filled with a certain algorithm later-on.
|
|---|
| 51 | * - Tesselation: Extend such that the created surface can be pushed away from
|
|---|
| 52 | * the atoms to resemble the molecular surface (http://en.wikipedia.org/wiki/Molecular_surface)
|
|---|
| 53 | * - all Actions regarding Filling: Filling should be generalized as to get a
|
|---|
| 54 | * shape and vector of atoms and to do something with it. Especially, not a
|
|---|
| 55 | * new Action but a token that just tells how to fill and a factory pattern
|
|---|
| 56 | * behind it that spits out the algorithm how to do it.
|
|---|
| 57 | *
|
|---|
| 58 | *
|
|---|
| 59 | * \date 2011-11-03
|
|---|
| 60 | *
|
|---|
| 61 | */
|
|---|
