Flow123d  jenkins-Flow123d-linux-release-multijob-282
input_type.hh
Go to the documentation of this file.
1 /*
2  * InputType.hh
3  *
4  * Created on: Mar 28, 2012
5  * Author: jb
6  *
7  * todo:
8 
9  * - explicit instantiation of templates in accessors - not so easy
10  *
11  * - TYPE is obligatory key of descendants of an AbstractRecord, for consistent documentation it should be reported as
12  * a obligatory key in these Records, however it is quite complicated to have it there , and it is not necessary for
13  * check of the input since we shall look for it explicitely.
14  *
15  * - Documentation of AbstractRecord should contain TYPE and common keys, descendants should report only nonderived keys.
16  *
17  * - better Doxygen doc
18  *
19  * - detailni popis pouziti deklaraci typu na systemu trid (v TypeBase)
20  *
21  * - Implementovat selection tak, aby typem Enum byla templatovana jen vnitrni datova struktura ( a pochopitelne access metody, ktere potrebuji
22  * presny typ, tj
23  * ...
24  *
25  * - have global list of Record and selection names and guarantee the they are unique, otherwise == can be incorrect.
26  *
27  * - when creating a "unique instance" of a lazy type we should check that its name is unique (in derived records we should
28  * distinguish short_name used in AbstractRecord TYPE selection, and full_name that includes name of the parent AbstractRecord.
29  * This is important to prevent Record derive from different local instances of AbstractRecord.
30  *
31  * When C++11 specification become more supported, we can introduce class Key that should be constructed form
32  * constant string during compilation, in particular it should check validity of the key string and compute the hash.
33  * This can provide some speedup for reading if it will be needed (probably not).
34  *
35  * - under C++11 we can also construct Selection s from the enum type
36  *
37  * - Question: allow implicit value of the TYPE key (and selection the descendant) depending on the keys that appears on the input.
38  * - Question: Support keys with multiple possible types:
39  * we declare more keys like: region_set_INTEGER, region_set_STRING, region_set_ARRAY, but user specify just
40  * region_set=..., and appropriate key is used.
41  *
42  * - non-polymorph inheritance of Records, in fact just copy of keys of one record to another + posibility to extend them
43  *
44  * Notes:
45  * - copy constructors and usage of Pimpl idiom for more complex types is necessary due to usage of shared pointers - to create them we need copies
46  */
47 
48 #ifndef INPUTTYPE_HH_
49 #define INPUTTYPE_HH_
50 
51 #include "type_base.hh"
52 #include "type_selection.hh"
53 #include "type_record.hh"
54 
55 #endif /* INPUTTYPE_HH_ */